- This topic has 58 hozzászólás, 7 résztvevő, and was last updated 16 years, 8 months telt el by
.
-
Bejegyzés
-
Ha a mysql írna ennyit, akkor nem kellene az atop listájában valami nagyobb értékkel megjelennie a mysql-nek vagy CPU vagy DISK használat képében? (A fenti atop az összes aktív processzt tartalmazza.) Nézegettem a mysql terhelést, de egészen minimálisnak tűnik. 1 max 2 lekérés egyszerre, az sem folyamatosan. A collectd semmi extrát nem mutat a mysql elemzésben.
Gyakorlatilag egy igazán látogatott oldal van a szerveren, de az sem portál, bár egy prado nevű keretrendszerben van írva. Egyetlen pradocache táblát használ az adatbázisban, ez is 170 sor csupán. Az oldalhoz tartozó teljes adatbázis mérete is csak 524KB.
Csatolok egy napi lemezhasználatot. Szerintem ez sokkal több írás, mint hogy néha a mysql rendet rak.Ha a mysql írna ennyit, akkor nem kellene az atop listájában valami nagyobb értékkel megjelennie a mysql-nek vagy CPU vagy DISK használat képében? (A fenti atop az összes aktív processzt tartalmazza.) Nézegettem a mysql terhelést, de egészen minimálisnak tűnik. 1 max 2 lekérés egyszerre, az sem folyamatosan. A collectd semmi extrát nem mutat a mysql elemzésben.
Gyakorlatilag egy igazán látogatott oldal van a szerveren, de az sem portál, bár egy prado nevű keretrendszerben van írva. Egyetlen pradocache táblát használ az adatbázisban, ez is 170 sor csupán. Az oldalhoz tartozó teljes adatbázis mérete is csak 524KB.
Csatolok egy napi lemezhasználatot. Szerintem ez sokkal több írás, mint hogy néha a mysql rendet rak.Úgy tűnik a feladatra a pidstat és iotop programok lennének valóak, de ezek 2.6.20-as kernel felett működnek csak. (Szükségük van az „I/O accounting support”-ra.) Az én kernelem 2.6.20-16-os, de ebben még nincs benne ez. Így vélhetőleg csak kernel frissítés után tudnám userekre bontani az io forgalmat … 🙁
Ha bárkinek van további építő ötlete, gondolata, örömmel olvasnám …Úgy tűnik a feladatra a pidstat és iotop programok lennének valóak, de ezek 2.6.20-as kernel felett működnek csak. (Szükségük van az „I/O accounting support”-ra.) Az én kernelem 2.6.20-16-os, de ebben még nincs benne ez. Így vélhetőleg csak kernel frissítés után tudnám userekre bontani az io forgalmat … 🙁
Ha bárkinek van további építő ötlete, gondolata, örömmel olvasnám …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.
Elgondolkoztatott, amit írtál. Egyrészt tényleg 10x-es az írás. Én csak vizuálisan probáltam saccolni, és már a 3x-ost sokalltam. Másrészt azonban nagyobb gondban vagyok ezzel a find-dal. Mert hát mikor adjam ki? Azt igazán nem értem, hogy a 10-15 percenkénti ritmust honnan olvastad le, de ha utánaszámolok, ez óránként kb. 80MB írás.
A dstat 1 kimenete pedig:Code:6 1 87 6 0 0| 147k 1003k| 0 0 | 387B 505B| 520 532
8 3 67 22 0 0| 0 2880k| 14k 304k| 0 0 | 764 1026
9 2 65 23 0 0| 0 2004k| 17k 322k| 0 0 | 559 833
10 3 65 22 0 0| 0 1888k| 30k 190k| 0 0 | 658 856
7 4 82 8 0 0| 560k 1020k| 27k 477k| 0 0 | 517 726
32 5 60 4 0 0| 28k 1400k| 34k 190k| 0 0 | 906 2383
3 1 92 5 0 0| 0 124k| 58k 665k| 0 0 | 920 312
0 0 71 28 0 0| 0 1536k| 34k 771k| 0 0 | 992 240
16 4 70 9 0 0| 32k 2056k| 22k 403k| 0 0 | 853 862Vagyis másodpercenként 1-2MB-ot ír, ami pont kiadja ezt a mennyiséget. Tehát nincs is igazán nagy írás egyszerre. Azért másodpercenként 1-2MB log csak nem készülhet!
Az fuser és lsof parancsokkal már néztem az írása nyitott fájlokat, de nem találtam szembeötlőt.
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.Elgondolkoztatott, amit írtál. Egyrészt tényleg 10x-es az írás. Én csak vizuálisan probáltam saccolni, és már a 3x-ost sokalltam. Másrészt azonban nagyobb gondban vagyok ezzel a find-dal. Mert hát mikor adjam ki? Azt igazán nem értem, hogy a 10-15 percenkénti ritmust honnan olvastad le, de ha utánaszámolok, ez óránként kb. 80MB írás.
A dstat 1 kimenete pedig:Code:6 1 87 6 0 0| 147k 1003k| 0 0 | 387B 505B| 520 532
8 3 67 22 0 0| 0 2880k| 14k 304k| 0 0 | 764 1026
9 2 65 23 0 0| 0 2004k| 17k 322k| 0 0 | 559 833
10 3 65 22 0 0| 0 1888k| 30k 190k| 0 0 | 658 856
7 4 82 8 0 0| 560k 1020k| 27k 477k| 0 0 | 517 726
32 5 60 4 0 0| 28k 1400k| 34k 190k| 0 0 | 906 2383
3 1 92 5 0 0| 0 124k| 58k 665k| 0 0 | 920 312
0 0 71 28 0 0| 0 1536k| 34k 771k| 0 0 | 992 240
16 4 70 9 0 0| 32k 2056k| 22k 403k| 0 0 | 853 862Vagyis másodpercenként 1-2MB-ot ír, ami pont kiadja ezt a mennyiséget. Tehát nincs is igazán nagy írás egyszerre. Azért másodpercenként 1-2MB log csak nem készülhet!
Az fuser és lsof parancsokkal már néztem az írása nyitott fájlokat, de nem találtam szembeötlőt.
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.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)?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)?
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz