Hozzászólások
-
SzerzőBejegyzés
-
Ami egyszer megtörténhet, az megtörténhet többször is. És ha most nem is volt belőle gond, a következő – ilyen értékek mellett – akár már mindet rommá dönthet …
Ami egyszer megtörténhet, az megtörténhet többször is. És ha most nem is volt belőle gond, a következő – ilyen értékek mellett – akár már mindet rommá dönthet …
Természetesen a logok voltak az elsők, amikben kerestem az okát. Sajnos semmi extrát nem találtam.
A terheltséget nálam egy crontab sor logolja, amelyik 5 percenként lefuttatja az uptime parancsot, és a kimenetet gyűjti egy fájlba. Az időpontokból is az látszik, hogy nem volt fennakadás.
A többi rendszer logban sincs semmi különleges bejegyzés. A bejegyzések ott is folyamatosak, nem utalnak leállásra, késlekedésre. (De persze nincs is bennük sok sor.)
A dmesg az indulási üzeneteken kívül semmi új sort sem tartalmaz.
A levelezés logjában sincs semmi különöns. Ezen az 5 percen belül talán ha 20-30 sor van összesen, az is leginkább a szürke lista visszautasításait tartalmazza.
A webszerver logja már nehezebb, mivel az virtuális hostonként szét van pakolva, de a szerver szintű logjai sem mutatnak semmit. (errors, suexec).Természetesen a logok voltak az elsők, amikben kerestem az okát. Sajnos semmi extrát nem találtam.
A terheltséget nálam egy crontab sor logolja, amelyik 5 percenként lefuttatja az uptime parancsot, és a kimenetet gyűjti egy fájlba. Az időpontokból is az látszik, hogy nem volt fennakadás.
A többi rendszer logban sincs semmi különleges bejegyzés. A bejegyzések ott is folyamatosak, nem utalnak leállásra, késlekedésre. (De persze nincs is bennük sok sor.)
A dmesg az indulási üzeneteken kívül semmi új sort sem tartalmaz.
A levelezés logjában sincs semmi különöns. Ezen az 5 percen belül talán ha 20-30 sor van összesen, az is leginkább a szürke lista visszautasításait tartalmazza.
A webszerver logja már nehezebb, mivel az virtuális hostonként szét van pakolva, de a szerver szintű logjai sem mutatnak semmit. (errors, suexec).Nem. Egyáltalán nem várom, hogy megmondja bárki is, hogy mi történt nálam, hisz ehhez tényleg kevés az információ. Csak azt reméltem, hogy valaki mond olyant, hogy mi történhetett. Mert szerintem már ebből is igen kevés van.
Ezt például nem tudtam, hogy a collectd tippel is, és nem csak mér. Pont ilyenekre vagyok kíváncsi, hogy legalább egy lehetséges, valószínű kép álljon össze.Nem. Egyáltalán nem várom, hogy megmondja bárki is, hogy mi történt nálam, hisz ehhez tényleg kevés az információ. Csak azt reméltem, hogy valaki mond olyant, hogy mi történhetett. Mert szerintem már ebből is igen kevés van.
Ezt például nem tudtam, hogy a collectd tippel is, és nem csak mér. Pont ilyenekre vagyok kíváncsi, hogy legalább egy lehetséges, valószínű kép álljon össze.Úgy látom, elfogytak az észrevételek. Akkor összefoglalom:
– 1694-es load érték még 4 processzoron is olyan terhelés, ami megakasztja a munkát. (Magam 1 processzoron éltem át 50-es load értéket, és az már finoman szólva is érezhető volt.)
– A load értéke tény.
– Az, hogy közben dolgoztam, és nem vettem észre, az is.Szerintem ez minden további információ nélkül is ellentmondás. Igazából azoknak szól ez a bejegyzés, akiket érdekel, hogy akkor mégis hogyan történhetett?
Az én tippjeim jelenleg (sajnos még mindig csak tippek):
1 – Lehet, hogy a 2.6-os kernel nagyon jól ütemezi a kicsi feladatokat, és a terhelést okozó processzek nagyok voltak?
2 – Lehet, hogy nagyon hirtelen futott meg a rendszer, és akkor épp nem gépeltem? Mondjuk egy percen belül lezajlik a terhelés, és én egy percig épp a chkrootkit-et futtattam, tehát nem gépeltem, így nem vettem észre. Ennek egy picit ellentmond, hogy a collectd szerint a load lefutása hosszabb volt, és szerintem még a kisebb értékeket is meg kellett volna éreznem.Részletkérdés, de továbbra sem értem, hogy a collectd miért csak 100-as load-ot muatat, ha az uptime 1694-et. Mivel mindkettő mér 1 perces értéket is, a legjobb esetben is 1 perc eltérés volt a kettő mintavétel között. Ha ez az 1 perc 1594 processz megszűnésével járt, akkor ez a második lehetőséget támasztja alá.
Úgy látom, elfogytak az észrevételek. Akkor összefoglalom:
– 1694-es load érték még 4 processzoron is olyan terhelés, ami megakasztja a munkát. (Magam 1 processzoron éltem át 50-es load értéket, és az már finoman szólva is érezhető volt.)
– A load értéke tény.
– Az, hogy közben dolgoztam, és nem vettem észre, az is.Szerintem ez minden további információ nélkül is ellentmondás. Igazából azoknak szól ez a bejegyzés, akiket érdekel, hogy akkor mégis hogyan történhetett?
Az én tippjeim jelenleg (sajnos még mindig csak tippek):
1 – Lehet, hogy a 2.6-os kernel nagyon jól ütemezi a kicsi feladatokat, és a terhelést okozó processzek nagyok voltak?
2 – Lehet, hogy nagyon hirtelen futott meg a rendszer, és akkor épp nem gépeltem? Mondjuk egy percen belül lezajlik a terhelés, és én egy percig épp a chkrootkit-et futtattam, tehát nem gépeltem, így nem vettem észre. Ennek egy picit ellentmond, hogy a collectd szerint a load lefutása hosszabb volt, és szerintem még a kisebb értékeket is meg kellett volna éreznem.Részletkérdés, de továbbra sem értem, hogy a collectd miért csak 100-as load-ot muatat, ha az uptime 1694-et. Mivel mindkettő mér 1 perces értéket is, a legjobb esetben is 1 perc eltérés volt a kettő mintavétel között. Ha ez az 1 perc 1594 processz megszűnésével járt, akkor ez a második lehetőséget támasztja alá.
A forgalmat már csak azért sem hiszem, mert akkor legalább valami ciklikusságnak kellene benne lenni. De ilyen eset eddig és ezóta sem soha nem fordult elő. Amúgy a load értéke 1 alatt van. Annak meg túl kicsi a valószínűságe, hogy épp ekkor és csak ekkor hirtelen ennyi forgalmat generáltak volna – szerintem.
A forgalmat már csak azért sem hiszem, mert akkor legalább valami ciklikusságnak kellene benne lenni. De ilyen eset eddig és ezóta sem soha nem fordult elő. Amúgy a load értéke 1 alatt van. Annak meg túl kicsi a valószínűságe, hogy épp ekkor és csak ekkor hirtelen ennyi forgalmat generáltak volna – szerintem.
-
SzerzőBejegyzés
legutóbbi hsz