Az ellentmondásosságomnak az lehet az oka, hogy nem igazán tudom, hol fogjam meg a problémát. Amikor az atop-ban látom, hogy a lemez 100%-ig foglalt (néha 101%, ami elég fura), és emellet a CPU wait 95%, valamint csak ír a lemez, azt gondolom, hogy ez a baj forrása. Amikor meg látom a dstat-on, hogy folyamatosan másodpercenként 1-2MB-ot ír, és ezzel kijön a napi 120G, akkor meg azt hiszem, ez a baj.
– Két 70GB-os SCSI winyó van a gépben, egyetlen teljesen hardveres RAID 1 tükörben. Más lemez nincs.
– A teljes fájlrendszer egy partíció.
– Ezen van a swap partíció is, ami 3GB.
– JSP, ASP nincs a gépen. Csak php fut. Elvileg sok lehet egyedi mindenféle, de nem igazán látok 2-3 domainnál több aktívat.
– Rsync csak úgy van a gépen, hogy minden hajnalban lefut egy távoili gépről. Napközben nincs.
Próbáltam find-dal megtalálni egy gyanús fájlt, de csak olyan fájlokat látok módosulni, amiken nem lepődom meg. Logok, mysql adatbázisok, session és tmp fájlok, eaccelerator cache-ek, beérkező levelek. (A levél forgalom szerintem elég alacsony.)
Annyit látok még a collectd alapján, hogy az írás mennyisége – úgy tűnik – arányos az apache kérelmek számával, ami arányos a mysql parancsok számával. De ezek alapján még akármi is lehet. Akár az apache, akár a mysql, akár a php, akár az eaccelerator, vagy akár valami rendszer bug. Mintha például nem használná rendesen a 4GB memóriát, hanem helyette mindig kiírna lemezre. Bár a collectd alapján a 4GB memóriából csak 1-et használ aktívan, a megmaradt kb. 3GB page cache.

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:

Vagyis 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.

Ú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 …

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.

Nem, nem lenne meglepő. Én sem vagyok biztos, pontosan mit is keresek. De az ilyen értékek egészen elbizonytalanítanak. (atop aktív processzek userenként csoportosítva.)

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.