RSYSLOG server: harddisk maakt overuren !!!

Citaat:

---

Oorspronkelijk geplaatst door systemdeveloper

Precies, vandaar dat het ook handig is om het even snel uit te sluiten met een tmpfs want zijn jdb2 loopt natuurlijk wel tegen de 100% aan en het ligt volgens de TS zeker aan de rsyslog. Ik krijg het zelf met rsyslog niet voor elkaar om een flinke disk load te krijgen. Maar ik heb ook geen servers die als een dolle de log aan het volpompen zijn.

Misschien is die syslog bak zijn eigen logs aan het rsysloggen en zit ie gewoon in een loop of zo...

---

Ik zie alleen niet wat je bereikt door syslog op tmpfs te laten schrijven. Het zal zeker sneller gaan, maar qua diagnose zegt dat toch niets ?

De test van TS _dat_ het rsyslog is, door die aan en uit te zetten en te zien dat alle load en gereutel daarmee ook aan en uit ging is m.i. ruim voldoende om te zeggen "is rsyslog" .

*Waarom* syslog zoveel disk io doet weten we dan niet zeker, maar (toch) fsync is wel de hoofdverdachte.
*Met* fsync zal het ook met een matige rate van logmessages prima lukken om een enorme disk io load te genereren.
Zonder fsync moet je dan wel heel grote volumes doen.

Jammer dat de strace tegen een probleem aan liep, want dat had de fsync() theorie goed bevestigd. (of ontkracht).

Citaat:

---

Oorspronkelijk geplaatst door visser

Ik zie alleen niet wat je bereikt door syslog op tmpfs te laten schrijven. Het zal zeker sneller gaan, maar qua diagnose zegt dat toch niets ?

---

Omdat je een probleem makkelijker kunt oplossen als je process niet op 100% loopt en wellicht een groot deel van zijn resources kwijt is aan memorymanagement, buffers vullen en flushen e.d.
Heb je een serieuze configfout (en eigenlijk vind ik dat knap aangezien een redelijk default config al redelijk wat kan hebben) of een buggy rsyslog/library dan zal de load van rsyslog misschien wel eens niet zoveel afnemen.

Aangenomen dat TS via zijn sudo natuurlijk wel de rechten voldoende heeft/of root is om strace uit te voeren (en niet op een virtualisatie laag zit die dat voorkomt, meen me te herinneren dat het bij openvz ook niet gaat, not sure tho) dan krijg die operation not permitted error eigenlijk alleen maar als je ergens tegen een kernel bug aanloopt. (of als er al een strace loopt).

Citaat:

---

Oorspronkelijk geplaatst door systemdeveloper

Omdat je een probleem makkelijker kunt oplossen als je process niet op 100% loopt en wellicht een groot deel van zijn resources kwijt is aan memorymanagement, buffers vullen en flushen e.d.
Heb je een serieuze configfout (en eigenlijk vind ik dat knap aangezien een redelijk default config al redelijk wat kan hebben) of een buggy rsyslog/library dan zal de load van rsyslog misschien wel eens niet zoveel afnemen.

Aangenomen dat TS via zijn sudo natuurlijk wel de rechten voldoende heeft/of root is om strace uit te voeren (en niet op een virtualisatie laag zit die dat voorkomt, meen me te herinneren dat het bij openvz ook niet gaat, not sure tho) dan krijg die operation not permitted error eigenlijk alleen maar als je ergens tegen een kernel bug aanloopt. (of als er al een strace loopt).

---

niet alle processen zijn te stracen....

Citaat:

---

Oorspronkelijk geplaatst door Mikey

niet alle processen zijn te stracen....

---

True, maar rsyslog wel bij mij iig. wel.