Re: mount / mit noatime.
Also sprach "Bruno Hertz" <brrhtz@yahoo.de> (Sun, 24 Apr 2005 22:25:38
+0200):
> Richard Mittendorfer <jkerdawn@yahoo.com> writes:
> >> Ich möchte gerne die nervigen 5 sekündigen Commits auf meiner ext3
> >/
> >
> > um den commit einzustellen gibt's AFAIK die mountoption
> > commit=<seconds>
> >
> >> Partition auf echte write requests reduzieren. Mount mit noatime
> >soll > da helfen, bin mir aber nicht sicher ob irgendein Systemdienst
> >auf > vernünftige access times angwiesen ist (Sarge/2.6).
> >
> > nix probelm. noatime bestimmt aber eher die menge der daten die
> > geschrieben werden muessen. ich empfehle bdflush (2.4.) bzw.
> > dirty_expire_centisecs und dirty_writeback_centisecs (2.6) zu tunen
> > und commit= hoeher zu setzen.
>
> Danke erstmal, es ist wie gesagt ein 2.6er Kernel.
>
> Eigentlich wollte ich das commit Intervall nicht höher setzen. Meine
> These war eher, daß selbst wenn keine echten Schreibanfragen vorliegen
> trotzdem Inode Access Times laufend upgedated werden und ich daher
> dauernd Flushes sehe. Mit noatime hoffte ich das unterbinden zu
> können.
>
> Scheint aber nicht zu stimmen. Ich habe einen remount noatime gemacht,
> und kjournald rödelt trotzdem munter weiter.
>
> Versuche, 'echte' Schreibzugriffe zu lokalisieren haben auch nichts
> gebracht.
plattenzugriffe & dein journal wird "sync".
> Per lsof habe ich mir alle offenen Dateien angesehen,
> hauptsächlich syslogd Log Dateien wie sich rausstellte, aber da rührt
> sich schreibmäßig nicht viel.
in der syslog.conf ein - (minus) vor die logdateien stellen. damit wird
das logfile nicht aktuell mit der platte gehalten.
> [...]
> Sehr undurchsichtig die Sache. Habe auch mal gegoogelt, und
> insbesondere Laptop Besitzer scheinen unter dem Thema zu leiden, von
> wegen APM und HD spin down. Kam aber trotzdem irgendwie nichts
> wirklich Nützliches rum.
ich find das a 'net klass. scheint, dass da einiges staendig auf die
platte will. in produktivem einsatz is'es aber sicher net so ung'scheit.
> Swapping sollte es eigentlich auch nicht sein, und warum das VM
> Subsystem dauernd dirty pages auf die Platte schreiben müßte sehe
> ebenfalls nicht. Naja, sei's drum.
IIRC ist das schreiben manchmal vom MM. grossteil aber halt journaling
fs. setz das commit mal hoeher, sysctl, und sieh mit einem dstat o.ae.
nach. ich hab meinen SOHO (bei mir SOcialHOming) server so recht ruhig
gestellt. daten sind dort sowieso auf ide: nfs,samba,apache,mserv
werden da gespeisst und die platte haelt automagisch. system ist auf
scsi.
bei scsi muesst den kernel patchen, fuer squid/mail aber auch nicht
moeglich/noetig.
wenn dein rechner nicht dauernd abschmiert (haha) oder du einen
unzuverlaessigen stromversorger hast kann ich's nur empfehlen.
> Vielen Dank also, Bruno.
sl ritch .o O (sollte es da nicht ein tool geben um jegliche zugriffe
auf datein mitzuloggen? dann koennte mensch das jeweiliges /dir doch ins
RAM werfen koennen? ext3 extended attributes?)
Reply to: