Hozzászólások
-
Bejegyzés
-
Először bogozzuk ki ami írtál.
linuxforum wrote:ha utánaszámolok, ez óránként kb. 80MB írás.linuxforum wrote:Vagyis másodpercenként 1-2MB-ot írAz átviteli grafikon alapján 1,4 MB/s az egyik 24 óra átlagos írása.
1,4MB/s * 60 = 84MB/perc
1,4MB/s * 60 * 60 = 5040MB/óra = ~4,92GB/óra (~5GB/óra)
1,4MB/s * 60 * 60 * 24 = 118GB/nap (~120GB/nap)linuxforum wrote:Azt igazán nem értem, hogy a 10-15 percenkénti ritmust honnan olvastad lelinuxforum wrote:Tehát nincs is igazán nagy írás egyszerre.A fentiek nincsenek összhangban azzal, amit eddig írtál. Nem tudok mit kezdeni veled, ha egyszer csak homlok egyenest mást írsz.
1. Van egy 400MB/s (terhelve 200-300MB/s) sebességű SCSI RAID tömböd.
2. 2-4 másodpercig 100%-os a terhelés és nagy I/O wait (=> 400-1200MB írása löketben), az mpstat másodpercenkénti eredményei alapján
3. óránént 5GB írásaKövetkeztetés: 10-15 percenként pár másodperces löketet kap a RAID tömb. Ha folyamatos lenne, akkor nem lenne 100%-os terhelés és nagy I/O wait.
linuxforum wrote:A dstat 1 kimenete pedig:Ha igaz amit ott szerepel, akkor van még egy vinyó a gépben (talán system+log+swap), amiről egy árva betűt sem írtál. Ez a lassú vinyó okozhatja a 100%-os terhelést és a wait értékeket.
linuxforum wrote:Másrészt azonban nagyobb gondban vagyok ezzel a find-dal. Mert hát mikor adjam ki?Amikor megjelenik a nagy I/O wait. Vagy már nem keresed mi okozza? Mi az amit most ki akarsz deríteni?
linuxforum wrote:Mellesleg mi van, ha nem fájlbaírás az az írás, amit keresek? Már csak azért is, mert a teljes felhasznált adatmennyiség 40GB körül van. Ebbe nem jöhet létre naponta 120GB új adat.Hát 4GB RAM és 2-300MB swap foglaltság mellett nem valószínű hogy nem fájlba írás a probléma okozója. Főleg nem kis terhelésű web szerveren.
linuxforum wrote:Azért másodpercenként 1-2MB log csak nem készülhet!De ha igen, akkor egy lassú vinyót képes löketben 100%-ban terhelni nagy I/O wait mellett. Ugyanis a napló fájlokat nem a szabványos C/C++ fájl műveletekkel illik kezelni, hanem a POSIX open() használatával O_DIRECT (szinkron írás) jelzéssel (aszinkron csatolású eszközön is szinkronban ír).
Újabb kérdések:
– hány vinyód (tömböd) van?
– melyik eszközön van a napló
– melyik eszközön van a swap
– mekkora a swap maximuma
– van-e fájl szinkronizáció a gépen (pl. rsync, ftp, stb)
– van-e egyedi (gagyi) PHP/JSP/ASP szkript a gépen ami esetleg fájlt beolvas-töröl-kiír (ez okozhat 12x-es írási többletet)?sany wrote:csili-vili ikon, parancs=”sudo rm -rf /*”
Ez biztosan lefut! ;DHa utána valami nem jó, akkor biztosan egy gonosz Linuxvírus okozta. ;D
sany wrote:csili-vili ikon, parancs=”sudo rm -rf /*”
Ez biztosan lefut! ;DHa utána valami nem jó, akkor biztosan egy gonosz Linuxvírus okozta. ;D
Valahogy így kellett volna feltenned az eredeti kérdést:
Hogyan tudom kideríteni, hogy alacsony forgalmú webszervernél alacsony (<10%) CPU használat mellet mi ír 10-15 perces időközönként nagyjából egyenletesen óránként 5GB-os mennyiséget (napi 120GB írás, óránkét 400MB olvasás) ami 100%-os írási terhelést okoz pár másodpercig (max. 400MB/s írási sebesség) magas I/O wait mellett?
Az 5GB és a 400MB között a különbség nem 3x, hanem 12,5x. Ez még SQL-nél is extrém. Ki tudod nyomozni, ha közvetlenül a terhelés után kiadod a
Code:find /RAID_PATH/ -type f -mmin -1 >~/modified_files.logparancsot. A válasz a fájlban lesz, csak meg kell találnod.
Valahogy így kellett volna feltenned az eredeti kérdést:
Hogyan tudom kideríteni, hogy alacsony forgalmú webszervernél alacsony (<10%) CPU használat mellet mi ír 10-15 perces időközönként nagyjából egyenletesen óránként 5GB-os mennyiséget (napi 120GB írás, óránkét 400MB olvasás) ami 100%-os írási terhelést okoz pár másodpercig (max. 400MB/s írási sebesség) magas I/O wait mellett?
Az 5GB és a 400MB között a különbség nem 3x, hanem 12,5x. Ez még SQL-nél is extrém. Ki tudod nyomozni, ha közvetlenül a terhelés után kiadod a
Code:find /RAID_PATH/ -type f -mmin -1 >~/modified_files.logparancsot. A válasz a fájlban lesz, csak meg kell találnod.
Ja hogy webszerver? Így mindjárt más.
linuxforum wrote:A lemez foglaltsága 101%, csak írás van, és egyetlen user sem foglalja lényegesen a lemezt. De akkor miért 101%?
Ráadásul a collectd adatai alapján összességében kb. 3-szor annyi a lemezre írás, mint a lemezről való olvasás, ami engem már magában is meglep, hisz alapvetően csak weboldalak és levelezés van a rendszerben.Egyszerű, mert a weboldalakhoz szükséges adatbázis kiszolgáló rendezgeti az indexelt táblákat a vinyón. Általában a rosszul agyonnaplózott portálok miatt van, mert minden oldal lekérés nagy mennyiségű adat beszúrással jár, de ezek ritkán vannak lekérdezve. Ezért 3x nagyobb az írás mennyisége. Találkoztam már többszáz megabájtos indexelt látogatási naplóval. Nézd meg a MySQL napló elemzéseket, mekkorák a táblák, mennyit ír a MySQL a vinyóra, stb. Ez az I/O terhelés tüske szerű, vagy több tíz másodpercig tart?
Ja hogy webszerver? Így mindjárt más.
linuxforum wrote:A lemez foglaltsága 101%, csak írás van, és egyetlen user sem foglalja lényegesen a lemezt. De akkor miért 101%?
Ráadásul a collectd adatai alapján összességében kb. 3-szor annyi a lemezre írás, mint a lemezről való olvasás, ami engem már magában is meglep, hisz alapvetően csak weboldalak és levelezés van a rendszerben.Egyszerű, mert a weboldalakhoz szükséges adatbázis kiszolgáló rendezgeti az indexelt táblákat a vinyón. Általában a rosszul agyonnaplózott portálok miatt van, mert minden oldal lekérés nagy mennyiségű adat beszúrással jár, de ezek ritkán vannak lekérdezve. Ezért 3x nagyobb az írás mennyisége. Találkoztam már többszáz megabájtos indexelt látogatási naplóval. Nézd meg a MySQL napló elemzéseket, mekkorák a táblák, mennyit ír a MySQL a vinyóra, stb. Ez az I/O terhelés tüske szerű, vagy több tíz másodpercig tart?
linuxforum wrote:De akkor marad a kérdés: ki ír ennyit a lemezemre???Nagyon meglepő lenne ha azt mondanám, hogy intenzív lemez olvasás + nagy hálózati forgalom (pl. adatbázis lekérdezés) is nagy eséllyel okozhat üzemszerűen hatalmas I/O terhelést alacsony CPU használattal? Egyáltalán megnézted a hálózati forgalmi adatokat, vagy elvből kizártad hogy nem okozhatja ezt a jelenséget?
linuxforum wrote:De akkor marad a kérdés: ki ír ennyit a lemezemre???Nagyon meglepő lenne ha azt mondanám, hogy intenzív lemez olvasás + nagy hálózati forgalom (pl. adatbázis lekérdezés) is nagy eséllyel okozhat üzemszerűen hatalmas I/O terhelést alacsony CPU használattal? Egyáltalán megnézted a hálózati forgalmi adatokat, vagy elvből kizártad hogy nem okozhatja ezt a jelenséget?
Sorry, nem /dev/null, hanem /dev/zero.
Helyesen:
Code:time dd if=/dev/zero of=/PATH/test.file bs=1024k count=100linuxforum wrote:Bár nem értem, ez a sor miért jó tesztnek, hisz 0 bájtos eredményt hoz létre.Eredeti szándék szerint egy 100MB-os nullákkal teli fájlt hoz létre. Lehetne akár mekkora, a /dev/zero a kiapadhatatlan nullák forrása.
legutóbbi hsz