Kedves Fórumozók!
Egy olyan problémával fordulok hozzátok, amit már napok óta nem tudok megoldani.
Adott egy szerver, rajta egy apache + php kombó, ubuntu alapokon, azure VPS-en (2mag, 3GB). Egy weboldal családot szolgál ki a szerver, napi kb 1000 látogatóval. Tehát elmondható a szerverről, hogy nulla terhelés. Ezek ellenére az apache kb 1 hete elkezdte azt játszani, hogy az egyik processe időről időre felugrik 130-160% CPU terhelésre, ott van egy 4mp-ig és eltűnik, majd jön egy másik 70%...stb. A gond akkor van, amikor ezek egyszerre jelennek meg, mert akkor 4-es loadot csinálnak a szerveren, miközben 3-4 látogató van az oldalon. Tehát ezt semmi nem indokolja.
A weboldalt én fejlesztettem a nullától, pontosan tudom, hogy mi van benne és mi nincs. Vannak benne szép query-k, de a slow_query logot megnézve naponta 1-2 olyan lekérdezés van, ami 2-3mp között fut, ezen kívül semmi megterhelő.
Tehát a világon semmi nem indokolja ezt a viselkedést, mégis ezt tapasztalom és nem tudok rájönni, hogy mi okozza. Tudnátok segíteni, hogy mi az, amit még nem próbáltam ki?
Amit megnéztem:
- apache logból legyűjtöttem a letöltött oldalak listáját számossággal együtt, keresve olyan kiugró lapokat, amiket mondjuk szándékosan terhelnek... nem találtam semmi kirívó értéket, a sitemapot többször töltötte le a google, mint a többi aloldalt a látogatók
- néztem apache server-status oldal, hogy hátha látok benne valamit, aminek nem kéne ott lenni, de semmi extrém
- cloudflare a dns kezelő, amibe bele tettem a web browser checker-t, ami szűri a botokat, de semmi eredmény
- htop, iotop, iftop, apachetop...stb. mindent néztem, figyeltem, de nem látok semmi olyat, ami ezt kéne hogy indokolja... ami mégis olyan volt, azt javítottam, kikapcsoltam, de még mindig ezt csinálja
- végig néztem az összes google találaton, hogy apache-ot megtuningoljam, minden lehetséges beállítást kipróbáltam, amit ajánlottak, de semmi előrelépés
- ugyan ez a mysql-en, aminél már olyan kapcsolókat is bekötöttem, amiknek a létezéséről sem tudtam, mindezidáig, de semmi...
- még az ubuntut is frissítettem, hogy hátha kijött valami újdonság, vagy javítás, de ez sem
De hogy miért érzem feleslegesnek a munkám? Mert nem csináltam a szerver beállításokkal semmit és a weboldalba se tettem semmit. Tehát kvázi semmivel nem okozhattam még is ezt lett. Támadást kizártam, mert ahol lehetett megnéztem, hogy pumpálják-e az oldalt, de semmi. Maximum, ha nem layer 7-en jön a támadás.
Nincs már ötletem. Mit lehet ilyenkor még megnézni? Mit lehet futtatni, mivel lehet tesztelni, mivel lehet közelebb jutni ahhoz, hogy mi eredményezi ezt a hülyeséget?
Bármilyen építő jellegű hozzászólást szívesen fogadok.
Hozzászólások
valamit mégiscsak a látogatók okoznak akkor, ha nagyobb a load amikor többen vannak
esetleg küldd meg rendesen valami load testing eszközzel (grinder pl.) abból kijöhet valami
--
Gábriel Ákos
Érdemes bekapcsolni a sokáig tartó php szkriptek naplózását:
slowlog = /var/log/php.slow.log
request_slowlog_timeout = 3s
Van minden látogatásról végrehajtási idő? Állítsd be az apache log-ot, hogy legyen. Azon szépen látni, hogy milyen gyakran jön elő és mely lekérdezések vezetnek oda: a te php projekted vagy egy assets/xy.js fájl vagy egy háttérkép.
Attól, hogy te nem változtattál az oldaladon, még lehet változás: kliens oldal. Az ügyfelek gépei lekérdezik az oldalad, pl. Chrome főképernyő.
Rendszeres időközönként jön elő? Ha mondjuk 30 percenként, akkor lehet a php session ürítése is, lásd cron.
Összességében: ott tudsz ülni annyit a gépnéál, hogy lásd a jelenséget? Mert akkor iotop, htop, dmesg.
Másik oldalról nincs-e egy jó adatkérés a phpbol?
Az szokott lenni...
2magos Azure gépnél garantáltan lassúak a diskek.
iostat, iotop amit először néznék. Többször belefutottunk hasonló lassulásokba a diskek miatt.
a probléma az, hogy iotop-nál nem látom, hogy olyan ördöngős terhelés lenne a diskeken... max 1,5-2Mb/s szokott lenni az olvasás és az írás egybe, értem én, hogy azure és olcsó gép, de azért ennyit elbír, kapott egy dd-t és ennek azért többszörösét tudta még véletlenszerű írás, olvasás esetén is
Az Azure nem olcsó. (Éves díj fizetéssel kezd baráti lenni.)
A sima diskenkénti max 500IOPS viszont elég kevés tud lenni, picit is komolyabb diskműveletnél.
iostat -x 1 és az IDLE érték az érdekes. Sokszor előfordul, hogy nulla, közben 1-2 MB/s az adatforgalom.
Szóval az iotop magában nem sokat ér.
Nem lehet, hogy ossztott magot használsz és a szomszéd terheli le a magot és nem Te?
ez könnyen előfordulhat, de erre a support úgysem válaszolna érdemben...
Ezeket nézném meg elsőre, hátha ezekből sikerül kiindulópontot elcsípni:
- PHP OpCache bekapcsolása, fölösleges apache és php modulok kilövése
- Futó MySQL lekérdezések ellenőrzése és szükség szerint időszakos logolása a SHOW FULL PROCESSLIST kimenetnek. Előfordulhat, hogy egy lekérdzés lockolja a táblát.
- MySQL táblatípusok lehetőleg InnoDB-n és a táblaméretek ellenőrzése.
- Apache serverstatus logolása a MySQL processlisthez hasonlóan.
- Valamilyen erőforrás monitoring, pl. munin, telepítése, hogy legyenek historikus adataid.
ha https az oldal, akkor tedd át az apache-ot event-ről worker modelre.
Ubuntun event a default, és voltak vele problémák, hasonló tünetekkel https kezelés kapcsán - bár leginkább nagyobb látogatottság esetén.
https az oldal, de nem a szerver szolgálja ki https-ben, hanem a cloudflare... ami annyit jelent, hogy a cloudflare és a szerver között sima http, majd Ő titkosít és adja tovább a kliensnek, nem a legjobb megoldás, de legalább van https és nem kell tanúsítványokat venni, a szerveren pedig csak a 80as port van nyitva a web részéről
sub
--
Mobilbarát és reszponzív weboldal készítés
+1
---
Why use Windows, if you have open doors… to Linux
Hasonlóval küzdök én is pár hónapja. Folyamatos 4-es load, bár nálam azért jóval nagyobb a valós terhelés illetve fut még PostgreSQL, Tomcat, stb...
Nem tudom ismered-e a GoAccess-t ? https://goaccess.io/
Ezen kibukott pár apróság, bár sokkal előrébb nem vagyok, de hátha neked hasznos.
----------------------------
Az emberiség valaha volt legnagyobb tévedése a dízel személyautó...
Ez hogy 4-es load pont nem mond semmit, lehet akár teljesen jogos is (mármint h nincs se alulméretezve se, meg algoritmikus hiba sincs)
Van egy site-unk ahol néha 20-as load van de nem tudunk mit tenni vele, backendre vár, aminek teljesítményét növelni esélytelen.
iowait ne legyen 10% fölött, cpu use ne legyen 80% fölött, akkor méretezésileg rendben vagy.
--
Gábriel Ákos
Igen. Én is úgy gondolom, hogy már nem nagyon tudok rajta reszelni többet. Esetleg a szerverben tudnám a HDD-t SSD-re kicserélni vagy az adatbázisokat egy külön SSD alapú szerverre tenni, de ez a jövő zenéje, erre most nincs kapacitásom...
----------------------------
Az emberiség valaha volt legnagyobb tévedése a dízel személyautó...
Ha _vár_ a backend-re és az egy másik gépen van, az nem okoz magas load értékeket... kivéve, ha pollozol és viszonylag gyakran.
végül egyébként örök homályba fulladt a probléma felderítése, aminek a megoldására soha nem fogok rájönni
újra indítottam a szervert, ami soha többet nem indult újra, ami már csak azért is nagyon furcsa, mert én semmit nem csináltam vele, ami ezt indokolta volna... vagyis most hogy jobban bele gondolok, a legutóbbi újraindulás óta feltettem az iotop és iftop parancsokat, lehet itt hibáztam...
szóval itt a szerver körül valami nagyon nagy gliccs volt, gondolom azure ezt soha nem ismerné be, de attól még ami igaz, az igaz... újraindulás utána a cp azt mutatta, hogy a szerver fut, de cpu, io...stb. terhelést nem mutatott és egyébként se csinált semmit... ssh-n elérni nem lehetett
ezért kénytelen voltam újra telepíteni a szervert, de most már ssd-re csatoltam fel a tárolókat és az ubuntu is ssd-re került fel... 2 óra munka árán visszakaptam ugyan azokat a configokat és ugyan azt a forráskódot, csak egy új szerveren és ssd-n... azóta a terhelésem nem megy 0.5 fölé
köszönöm mindenkinek a tippet és az ötletet a javaslatok mindenképpen hasznosak voltak, mert legközelebb lesz még pár ötlet, amit meg tudok próbálni