Onderwerp: 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 ?

Oorspronkelijk geplaatst door Mikey

wat zegt iotop ?

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

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

Oorspronkelijk geplaatst door askmurphy

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

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.

Oorspronkelijk geplaatst door systemdeveloper

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.

Oorspronkelijk geplaatst door askmurphy

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.

Oorspronkelijk geplaatst door systemdeveloper

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.

Oorspronkelijk geplaatst door visser

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