> From: Jafa <j...@silicondust.com> > To: fail2ban-users@lists.sourceforge.net > Subject: Re: [Fail2ban-users] fail2ban quickly killing SSDs > Message-ID: > <caf_2unklg54kgawzx74uckymbffp75ob6x0n_efwaam9_+m...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Sun, Jul 16, 2017 at 9:37 AM, Jafa <j...@silicondust.com> wrote: > >> I noticed the SSD lifespan numbers dropping rapidly on some servers - >> losing a percent every 1-2 days. The wear leveling count was incrementing >> about once an hour. >> Figure 125 days for a new SSD to reach 0% lifespan remaining. >> >> fail2ban was using a sqlite DB... 130k in size. >> Changing the configuration to :memory: fixed the problem - writes all but >> disappeared. >> >> Looking at sqlite... >> 1) The sqlite DB is causing high disk writes - ~600kB/s to disk with a >> 130k DB file. >> 2) The sqlite DB appears to be writing very small chunks of data resulting >> in a high write amplification factor. >> 3) The sqlite DB appears to be forcing a sync to disk at a high rate. >> Rewriting part or all of a 130k file should be cached and result in very >> little write load. >> >> I suspect configuring sqlite not to force a sync to disk, or to force the >> sync at a slower rate, say once every 5 seconds, would solve the problem. >> > > Answering my own question - it looks like this problem was fixed in > fail2ban 0.10 which sets "PRAGMA synchronous=OFF”.
So there’s no way to do this in the 0.95 version? ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Fail2ban-users mailing list Fail2ban-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fail2ban-users
