Tätä en ollut luullut että ihan heti kirjoitan kun oon seurannut ukkospäivien liikennettä, nimittäin aika tasaisia ovat nuo kolina-päivät olleet liikenteen osalta kun kävijämäärää katsoo.
Joka tapauksessa, eilen 8.6 rikottiin taas yksi raja ja ennätys laitettiin uusiksi reilusti, yli 20%:lla vanhaan nähden.
Nimittäin sivulatauksissa meni rikki 300 kilon raja ollessa Google Analyysin mukaan 308000 sivultausta. Vanha ennätys oli 248k. Istuntoja oli 107k ja kävijöitä 58000. :) 8)
Mitä palvelimen tökkimiseen tulee niin asiaa pitää ainakin seurata ja laittaa pari prosessi-tappajaa kehiin ajastuksella niiden osalta mitä nyt 2 päivänä nähnyt että jäänyt roikkumaan ja jos siitä on tulossa uusi vakio kolinapäiväinä niin luonnollisesti asialle pitää pidemmällä tähtäimellä jotain tehdä.
Lainaus käyttäjältä: weatherc - sunnuntai, 09.06.2019, 18:13
Mitä palvelimen tökkimiseen tulee niin asiaa pitää ainakin seurata ja laittaa pari prosessi-tappajaa kehiin ajastuksella niiden osalta mitä nyt 2 päivänä nähnyt että jäänyt roikkumaan ja jos siitä on tulossa uusi vakio kolinapäiväinä niin luonnollisesti asialle pitää pidemmällä tähtäimellä jotain tehdä.
Kai sulla on joku zabbix tms. monitorointisofta siellä et näet missä se ongelma on?
Lainaus käyttäjältä: khyron - sunnuntai, 09.06.2019, 21:26
Kai sulla on joku zabbix tms. monitorointisofta siellä et näet missä se ongelma on?
Eip. Mutta HTOP:ia seuraamalla näki aika hyvin roikkuvat prosessit ja muutoin on tuollainen status-sivu jossa koko fyysisen serverin että virtuaalien strateegiset arvot printtaantuu kerran minuutissa. Nämä 2 päivää se ei kyllä kertonut muuta kun että loadit katossa ja CPU:t 100%:ssa ja että lämpötila alko olemaan sauna-luokkaa (n 80 astetta) ;)
Mutta, veikkaus on että iski myös domino-efekti. Ja ainakin kartta/websocketti-virtuaalilla oli joku php-häkkyrää tahikka php-fpm tehnyt bänät, php-prosesseja oli vajaat 100 käynnissä, ja se rauoittui sillä että käynnisti php-fpm:än uudestaan. Ja se vaikutti myös webbi-virtuaaliin rauhoittavasti.
IO:t eivät ollut ongelma koska kartat tehdään lähes kaikki suoraan RAM:iin alkaen datojen latauksista, samoin BO:n websockettidata menee RAM:iin, kartta-virtuaalin IO oli iotopin mukaan käytännössä nollassa.
Lainaus käyttäjältä: weatherc - sunnuntai, 09.06.2019, 22:10
Lainaus käyttäjältä: khyron - sunnuntai, 09.06.2019, 21:26
Kai sulla on joku zabbix tms. monitorointisofta siellä et näet missä se ongelma on?
Eip. Mutta HTOP:ia seuraamalla näki aika hyvin roikkuvat prosessit ja muutoin on tuollainen status-sivu jossa koko fyysisen serverin että virtuaalien strateegiset arvot printtaantuu kerran minuutissa. Nämä 2 päivää se ei kyllä kertonut muuta kun että loadit katossa ja CPU:t 100%:ssa ja että lämpötila alko olemaan sauna-luokkaa (n 80 astetta) ;)
Mutta, veikkaus on että iski myös domino-efekti. Ja ainakin kartta/websocketti-virtuaalilla oli joku php-häkkyrää tahikka php-fpm tehnyt bänät, php-prosesseja oli vajaat 100 käynnissä, ja se rauoittui sillä että käynnisti php-fpm:än uudestaan. Ja se vaikutti myös webbi-virtuaaliin rauhoittavasti.
IO:t eivät ollut ongelma koska kartat tehdään lähes kaikki suoraan RAM:iin alkaen datojen latauksista, samoin BO:n websockettidata menee RAM:iin, kartta-virtuaalin IO oli iotopin mukaan käytännössä nollassa.
Historiastahan näkis mistä on alkanu, yleensäkin hankala korjata asioita jollei o selkeetä tietoa syystä.
Lainaus käyttäjältä: khyron - sunnuntai, 09.06.2019, 22:26
Historiastahan näkis mistä on alkanu, yleensäkin hankala korjata asioita jollei o selkeetä tietoa syystä.
Sanoisin ettei välttämättä mikään yksittäinen vaan että yksi hidastuminen johti toiseen ja niin edelleen. Sivuilla, siis myös muilla dedin sivustoilla kuin omillani, on skriptejä jotka ovat suht raskaat/hitaat ja jotka toimivat ihan ok normi liikenteellä mutta kun enemmän liikennettä niin näköjään alkaa tökkimään. Siihen viitaisi ainakin mitä seurasin Htoppia, yleensä sinne ei listaannu kun EWN:ään liittyvät hitaat datanhaku-skriptit mutta nytten siellä kiikkui muutama sivu-skriptikin. Nämä, ainakin nimien perusteella, olivat sellaisia jotka hakevat myös dataa ulkopuolelta, tyyliin WU:lta. Nuo Saratoga-templaten häkkyrät kun ei välttämättä ole tehty liikennettä ajatellen.
Webbi-virtuaalin Cpanel lähettää "high load"-maileja kerran tunnissa kun tarve on. Se sisältää mm ps:ää, netstat:ia seka Apachen status-sivua. Lauantain ensimmäisessä mailissa olevista niin näkee että
- netstatin mukaan yli 6000 yhteyttä auki joista iso kasa TIME_WAIT statuksella
- ps:ssä ei mitään kummallista, pari php-häkkyrää takoi CPU:ta sekä, yllätys, yllätys, mysli. Mysli oli CPU-rohmu myös mitä seurasin Htoppia.
- Apachella 160 serveriä auki (Webbi-virtuaali toimii Nginx frontend + Apache backend kombolla). Siinä kiikku samat php-häkkyrät mitä sain irti Htopillakin.
Yks asia minkä oppinut näinä vuosina kun tuon dedin kanssa ropeltanut on että "high traffic server" ym-ohjeitahan on netti pullollas, mutta jokainen kertoilee vähän eri asioita tai jopa samoja asetuksia ollaan säätelemässä mutta eri arvoin. Paras lienee trial-error tähän(kin) koska setuppeja/käyttötarkoituksiahan on niin monenlaisia...
Yksi useasti esiin tulevista on nuo sysctl-arvot. Näillä mennään nyt seuraavaan ukkoseen (reuse/recycle olivat nollassa ja timeoutti oletus 60:ssä):
net.ipv4.tcp_fin_timeout=25
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
Yksi jota ei viikonloppuna ruuhkan aikana tullut mieleen tarkistaa oli mysqlin mysql-tuner. Ja esim EWN:än data-päivityksethän oli aika lailla jumissa ruuhkan aikana. Max_connections on ollut 200:ssa tähän asti ja nyt kun tarkistin viime vuorokauden arvot niin on max ollut 48 yhteyttä. Nostin tuon 300:aan mikä mahtuu vielä aivan lostavasti ettei syötetä ihan kaikkea RAM:ia sille ;)
Lainaus käyttäjältä: weatherc - maanantai, 10.06.2019, 11:55
Lainaus käyttäjältä: khyron - sunnuntai, 09.06.2019, 22:26
Historiastahan näkis mistä on alkanu, yleensäkin hankala korjata asioita jollei o selkeetä tietoa syystä.
Sanoisin ettei välttämättä mikään yksittäinen vaan että yksi hidastuminen johti toiseen ja niin edelleen.
Noinhan se toki yleensä käy, ja silloin se ensimmäinen on se juurisyy joka ensin kannattaa korjata.
Lainaus käyttäjältä: weatherc - maanantai, 10.06.2019, 16:26
Yks asia minkä oppinut näinä vuosina kun tuon dedin kanssa ropeltanut on että "high traffic server" ym-ohjeitahan on netti pullollas, mutta jokainen kertoilee vähän eri asioita tai jopa samoja asetuksia ollaan säätelemässä mutta eri arvoin. Paras lienee trial-error tähän(kin) koska setuppeja/käyttötarkoituksiahan on niin monenlaisia...
Juuei, parempi on selvittää missä se ongelma on ja sen jälkeen korjata se. Satunnaisesti roiskimalla voi toki asua tuurilla, mutta ei se kovin tehokasta ole.
Lainaus käyttäjältä: khyron - maanantai, 10.06.2019, 17:19
Noinhan se toki yleensä käy, ja silloin se ensimmäinen on se juurisyy joka ensin kannattaa korjata.
Totta.
Mutu on että
- kartta-virtuaalilla oli syypää se php(häkkyrä) joka tilttas syystä tai toisesta. Htop ei kyllä kertonut mikä kartta se oli joka failas mutta aavistus on kyllä olemassa. Joka tapauksessa lisäsin sinne että kaikki php:t tapetaan kerran tunnissa sopivalla minuutilla jolloin ei ole mitään ajastusta käynnissä :)
- webbi-virtuaalilla on mutu että yksi syypää oli - yllätys, yllätys - mysli. Ja että siinä meni max_connectionit katosta läpi. Ei olis ensimmäinen kerta näiden vuosien varrella kun siitä tulee ongelma kun on enemmän liikennettä. Tähän viittaisi myös se että mm EWN:än datahaut failasi. Sitä pitää toki seurata seuraavalla kerralla kun on enemmän liikennettä.
Lainaus käyttäjältä: khyron - maanantai, 10.06.2019, 17:19
Juuei, parempi on selvittää missä se ongelma on ja sen jälkeen korjata se. Satunnaisesti roiskimalla voi toki asua tuurilla, mutta ei se kovin tehokasta ole.
Totta :)
Onko siellä samalla koneella siis jotain eräajoja? Kai kaikilla ei kiireellisillä on riittävän korkee nice asetettuna?
Lainaus käyttäjältä: khyron - tiistai, 11.06.2019, 16:53
Onko siellä samalla koneella siis jotain eräajoja? Kai kaikilla ei kiireellisillä on riittävän korkee nice asetettuna?
Samalla fyysisellä konella on sekä tutkadatat että EWN:än datahaku ajastettuina. Noilla on kaikilla nicet laitettu, muistaakseni 19 ellen väärin muista näin tarkistamatta. Muita ajastuksiahan on sitten kaikki webbisivujen/sääasemien omat cronit.
Tuossa sivusilmällä seuraillut pikkasen nuita virtuaaleja, ja varsinkin tänään kun vähän enemmän liikennettä (ihan hyvin porskuttanut)...
Sanoisin ettei välttämättä mikään yksittäinen juttu joka ongelman aiheutaa. Tosin CPU (i7-7700) raksuttaa aikas kovilla.
Dedillä on 8 corea joista virtuaalit ovat saaneet 4 + 4. Tiedän että Proxmoxissa voisi antaa niille 8 + 8 ja antaa niiden tapella resursseista oman mielen mukaan. Tota voisi ehkä kokeilla. Joskin juuri nyt en viitti rebootata nuita.
Kartta-virtuaalissa ainakin tuuppaa nuo 4 olla käytössä kun, 1 x BO websocketille, parit generoi tutkatiiliä/karttoja, Nginx:llä 4 prosessia, yks parsii YR ennustetta, yks parsii norsken sadetutkaa jne. Ja unohtamatta videot kerran tunnissa FMI- ja BO-kuville ffmpeg:llä ;)
Webbi-virtuaalissa taas mysli haukkaa aika usein 2 coren tehot aika huolella.
Lainaus käyttäjältä: weatherc - torstai, 13.06.2019, 19:54
Tuossa sivusilmällä seuraillut pikkasen nuita virtuaaleja, ja varsinkin tänään kun vähän enemmän liikennettä (ihan hyvin porskuttanut)...
Sanoisin ettei välttämättä mikään yksittäinen juttu joka ongelman aiheutaa. Tosin CPU (i7-7700) raksuttaa aikas kovilla.
Dedillä on 8 corea joista virtuaalit ovat saaneet 4 + 4. Tiedän että Proxmoxissa voisi antaa niille 8 + 8 ja antaa niiden tapella resursseista oman mielen mukaan. Tota voisi ehkä kokeilla. Joskin juuri nyt en viitti rebootata nuita.
Kartta-virtuaalissa ainakin tuuppaa nuo 4 olla käytössä kun, 1 x BO websocketille, parit generoi tutkatiiliä/karttoja, Nginx:llä 4 prosessia, yks parsii YR ennustetta, yks parsii norsken sadetutkaa jne. Ja unohtamatta videot kerran tunnissa FMI- ja BO-kuville ffmpeg:llä ;)
Webbi-virtuaalissa taas mysli haukkaa aika usein 2 coren tehot aika huolella.
Saat tämän FinWX:n infrakaluston ylläpitotoimeni kuulostamaan melkoiselta pienen piirin amatööripuuhastelulta. ;D
Tosin minulla ei ole tutkadatan parsintaa, tiilien generointia tai kuvadatan yhdistämistä videoksi käynnissä.
Lainaus käyttäjältä: J.Jäntti - maanantai, 17.06.2019, 08:34
Saat tämän FinWX:n infrakaluston ylläpitotoimeni kuulostamaan melkoiselta pienen piirin amatööripuuhastelulta. ;D
Tosin minulla ei ole tutkadatan parsintaa, tiilien generointia tai kuvadatan yhdistämistä videoksi käynnissä.
;D
Molempien virtuaalien yhteenlaskettu kuukausiliikenne kiikkuu vnstatin mukaan näin kesäsin siinä 4 TiB korvilla ;D 8)
Lainaus käyttäjältä: weatherc - maanantai, 17.06.2019, 16:21
Molempien virtuaalien yhteenlaskettu kuukausiliikenne kiikkuu vnstatin mukaan näin kesäsin siinä 4 TiB korvilla ;D 8)
Olisikohan se noin 15 Mbps tasaista vauhtia.. Tuon 4,4 TB:n lataaminen kestäisi noin 3,5 viikkoa 3/4g -mokkulalla 20 Mbps keskiarvolla.. sellaista 8,5 GB:n tuntivauhtia/ 200GB vrk:ssa..>> ainakin 22-23 vrk:tta yhtäsoittoa putkeen.... saattaapi olla että operaattorit reagoi vaika rajattomia ovat yhteydet.. ;D ::)
Lainaus käyttäjältä: weatherc - torstai, 13.06.2019, 19:54
Tuossa sivusilmällä seuraillut pikkasen nuita virtuaaleja, ja varsinkin tänään kun vähän enemmän liikennettä (ihan hyvin porskuttanut)...
Sanoisin ettei välttämättä mikään yksittäinen juttu joka ongelman aiheutaa. Tosin CPU (i7-7700) raksuttaa aikas kovilla.
Dedillä on 8 corea joista virtuaalit ovat saaneet 4 + 4. Tiedän että Proxmoxissa voisi antaa niille 8 + 8 ja antaa niiden tapella resursseista oman mielen mukaan. Tota voisi ehkä kokeilla. Joskin juuri nyt en viitti rebootata nuita.
Toi ei välttämättä o hyvä ajatus, mun ymmärtääkseni jos virtuaalille antaa vaikka ton neljä prossua niin sit neljän coren pitää olla samaan aikaan vapaana et päästään ajoon. Eli olis järkevämpää laittaa aina yks asia per virtuaali ajoon ja sit useempi virtuaali, ja joka virtuaalille mahdollisimman vähän coreja. https://blog.heroix.com/blog/vmware-vcpu-over-allocation (https://blog.heroix.com/blog/vmware-vcpu-over-allocation) tuolla co-stop kohdassa on asiasta enemmän, kyse on vmwaresta, mut vois olettaa et kaikki alustat toimii samalla tavalla.
Lainaus käyttäjältä: khyron - maanantai, 17.06.2019, 21:03
https://blog.heroix.com/blog/vmware-vcpu-over-allocation (https://blog.heroix.com/blog/vmware-vcpu-over-allocation) tuolla co-stop kohdassa on asiasta enemmän, kyse on vmwaresta, mut vois olettaa et kaikki alustat toimii samalla tavalla.
Siinäpä se kiva pikkujuttu onkin, että nuo eivät ole ihan suoraan verrannollisia keskenään. VMware toimii Proxmoxiin verrattuna kaikilta osin varsin eri tavalla, myös tavalla, jolla se ottaa virtualisointialustan raudan haltuunsa.
VMware on rakennettu aika lailla kokonaan suljettua lähdekoodia käyttäen, kun Proxmoxilla mennään open source-pohjalla, KVM:n ja Debianin päällä, joten jo tuossa mennään tilanteeseen jossa merkittäviä eroja on oltava pakosti ettei homma mene jonkinlaiseksi patenttikiistaksi VMwaren suunnalta alta aikayksikön.
Itselläni on ollut molempia käytössä, mutta VMwaren varsin nuiva suhtautuminen kotiservereihin (tyyliin "No ECC RAM, no service/help") ja siihen miten erinäisiä rautakomponentteja (esim. RAID-ohjaimia tai North Bridgejen levyohjaimia) pudotetaan versiopäivityksissä ulos niin, että niiden toiminnallisuus joko muuttuu ihan toisenlaiseksi (lue: geneerisemmäksi) tai katoaa tyystin, pakotti lopulta luopumaan heidän pillinsä mukaan tanssimisesta ja suuntaamaan katse Proxmoxiin. Proxmox mahdollistaa myös sellaisiakin toimenpiteitä tehtäväksi ihan ilmaiseksi, joiden tekeminen VMwaressa vaatisi erinäisten featurejen lisäämistä lisenssiin pirullisella nipulla satasia. Se taas ei onnistu ilman heidän sertifioimaa serverirautaa, joka sinulla sitten kuuluu olla hankittuna.
Lainaus käyttäjältä: khyron - maanantai, 17.06.2019, 21:03
https://blog.heroix.com/blog/vmware-vcpu-over-allocation (https://blog.heroix.com/blog/vmware-vcpu-over-allocation) tuolla co-stop kohdassa on asiasta enemmän, kyse on vmwaresta, mut vois olettaa et kaikki alustat toimii samalla tavalla.
Kuten Jäntti sanoi, tässä se juju onkin ettei toimi.
Dedin virtuaalit ovat KVM:iä, ja vaikuttaa itse asiassa siltä että rauhallisemmin raksuttaa nyt kun ollut muutaman päivän 8 + 8 asetuksella sekä "host" CPU:lla, eli samat mitä fyysinenkin on (host oli aikasemminkin). Proxmoxin ohjeessa itse asiassa lukee että voi antaa yhtä monta corea jokaiselle virtuaalille mitä fyysisestikin on olemassa, joskin ei enempää.
Lainaa
It is perfectly safe if the overall number of cores of all your VMs is greater than the number of cores on the server (e.g., 4 VMs with each 4 cores on a machine with only 8 cores). In that case the host system will balance the Qemu execution threads between your server cores, just like if you were running a standard multithreaded application. However, Proxmox VE will prevent you from assigning more virtual CPU cores than physically available, as this will only bring the performance down due to the cost of context switches.
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_virtual_machines_settings
Aikasempi 4 + 4 perustui juuri tuohon ajatukseen mitä sanoit, eli että molemmilla olisi "omat" 4 corea eikä "häiritsisi" kaveria.
Miten KVM sitten varaa prosessoreita guestille?
Lainaus käyttäjältä: khyron - tiistai, 18.06.2019, 17:53
Miten KVM sitten varaa prosessoreita guestille?
Ymmärtääkseni ei mitenkään vaan toimii kuten mikä tahanhansa multitasking-ohjelma. Mutta on cpuunits ja cpulimit-asetukset joista toinen toimii tavallaan paino-arvona eli esim jos toisella on 1024 ja toisella 2048 niin saa toinen 2/3 cpu-bandwidth:stä sekä suuremman priorisoinnin.
Tuossa aikasemmin linkitetyssä Proxmoxin ohjeessa on tarkemmin siitä.