Bekijk Volledige Versie : RSYSLOG server: harddisk maakt overuren !!!
Even een vraagje: heb een nieuwe Rsyslog server opgezet waar nu alle logs van de diverse hostingservers naar toe worden gestuurd.
Via de geïnstalleerde LogAnalyzer hebben we nu een centraal punt waar alle logs van alle servers bij elkaar komen en met deze tool kun je het een en ander prima monitoren. Mooie aanvulling naast onze ZABBIX server ;-)
Nu heb ik echter 1 probleem: de harddisk van de Rsyslog server maakt overuren................
Zodra ik de rsyslog server stop is de harddisk weer rustig. Geheugen en schijfruimte genoeg.
Loop al de hele dag te zoeken naar het euvel, tot nu toe niet gevonden.
Komt meer voor (google) maar nog geen oplossing gevonden.
Wie kent dit en weet hoe dit is op te lossen ?
(zal deze rsyslog server straks maar weer uitzetten, anders gaat die harddisk deze week nog de pijp uit ;-)
RSyslog instellen dat niet na elke logentry een flush (sync) wordt gedaan richting het filesystem. Kan volgens mij door een "-" voor de logfile naam te zetten.
Had ik al gedaan, helpt niet. Alles werkt prima hoor, maar zo'n ratelende harddisk doet dat meestal niet al te lang....
Tja, wat is dit nu: te veel data aanbod (moet wel meevallen als ik de inkomende logs zie) of doet rsyslog andere rare dingen...
wat zegt iotop ?
12119
Zie screendump ;-)
Zodra ik de Rsyslog service uit zet dan is alles weer rustig.
Dit is een servertje (Atom 8 core) die gebruikt wordt voor vanalles en nog wat:
backupserver, Zabbix-server en nu dan Rsyslog met LogAnalyzer.
De data komt allemaal binnen en is ook mooi te bekijken via LogAnalyzer, alleen het diskgebruik is veel te hoog.
Zou mooi zijn als dat op te lossen is.
Zo heel veel is hij niet aan het doen...
dennis0162
24/03/15, 17:51
Ik kan het screenshot niet goed zien op m'n telefoon. Maar is een Atom niet wat zwak voor al die services?
Onze Zabbix server en syslog server draait op een 4 core server met 8gb ram anders loopt de boel vast.
Verzonden vanaf mijn iPhone met behulp van webhostingtalk
12119
Zie screendump ;-)
Zodra ik de Rsyslog service uit zet dan is alles weer rustig.
Dit is een servertje (Atom 8 core) die gebruikt wordt voor vanalles en nog wat:
backupserver, Zabbix-server en nu dan Rsyslog met LogAnalyzer.
De data komt allemaal binnen en is ook mooi te bekijken via LogAnalyzer, alleen het diskgebruik is veel te hoog.
Zou mooi zijn als dat op te lossen is.
Toch denk ik dat je wel een sync doet na iedere syslog write, alle symptomen suggereren dat.
Je kunt met strace -f -p <pid van rsyslogd> kijken welke syscalls je ziet langskomen.
Kijk nog eens heel goed of die '-' wel goed staat, en m.n. voor elke file waar frequente writes naar toe gaan.
heb strace nog even gedaan: ot@matrix:~# sudo strace -f -p 1652
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
Sent from my SM-G900F using webhostingtalk mobile app
server heeft 8gb intern, een atom c2750 (8cores). met rsyslog draaiend: cpu kleiner dan 20%. met rsyslog uit is de cpu belasting kleiner dan 1%.
lijkt er op dat de rsyslog configuratie niet goed is.. wie kan eens een bij zich zelf werkende rsyslog laten zien ? Zal die van mij morgen hier even posten. Allemaal heel erg bedankt voor de hulp hoor !!!
Sent from my SM-G900F using webhostingtalk mobile app
systemdeveloper
25/03/15, 22:16
Ik zou eerst eens kijken hoeveel iops dat bakkie kan doen (want jdb2 op 100% geeft meestal aan dat je gewoon een zwaar tekort hebt daaraan) en eens kijken of je een journaling filesystem gebruikt voor je logs (eventueel overstappen op een ander fs).
De makkelijkste manier om het even te testen lijkt me om een tmpfs van een paar gb te maken en daar je logs op te mikken.
Ik zou eerst eens kijken hoeveel iops dat bakkie kan doen (want jdb2 op 100% geeft meestal aan dat je gewoon een zwaar tekort hebt daaraan) en eens kijken of je een journaling filesystem gebruikt voor je logs (eventueel overstappen op een ander fs).
De makkelijkste manier om het even te testen lijkt me om een tmpfs van een paar gb te maken en daar je logs op te mikken.
Wellicht de journaling aanpassen dan, deze is genoeg te tweaken zonder over te stappen.
heb strace nog even gedaan: ot@matrix:~# sudo strace -f -p 1652
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
Sent from my SM-G900F using webhostingtalk mobile app
Daar heb ik geen ervaring mee (wel strace gebruikt, deze melding niet meegemaakt), maar google geeft een paar suggesties voor als je deze melding krijgt.
Overigens is het voornaamste wat je ermee bereikt een bevestiging of rsyslog inderdaad veel fsyncs doet.
Ik zou eerst eens kijken hoeveel iops dat bakkie kan doen (want jdb2 op 100% geeft meestal aan dat je gewoon een zwaar tekort hebt daaraan) en eens kijken of je een journaling filesystem gebruikt voor je logs (eventueel overstappen op een ander fs).
De makkelijkste manier om het even te testen lijkt me om een tmpfs van een paar gb te maken en daar je logs op te mikken.
Het zou wel heel veel log data moeten zijn als 'normale' logging zonder fsync aan iops tekort komt.
(@TS : wat voor logvolumes gaat het eigenlijk om, in (M/K) bit/sec of regels/sec ? )
Dit klinkt een beetje als tips om je motor meer vermogen te geven terwijl je rijdt met de handrem erop.
systemdeveloper
26/03/15, 11:59
Het zou wel heel veel log data moeten zijn als 'normale' logging zonder fsync aan iops tekort komt.
(@TS : wat voor logvolumes gaat het eigenlijk om, in (M/K) bit/sec of regels/sec ? )
Dit klinkt een beetje als tips om je motor meer vermogen te geven terwijl je rijdt met de handrem erop.
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...
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).
systemdeveloper
26/03/15, 14:25
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).
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....
systemdeveloper
26/03/15, 15:55
niet alle processen zijn te stracen....
True, maar rsyslog wel bij mij iig. wel.