On Sun, Jul 15, 2018 at 12:21:51PM +1000, Dmitry Smirnov wrote: > On Sunday, 15 July 2018 7:24:15 AM AEST Mike Hommey wrote: > > sqlite doesn't work well on NFS. That's a long standing known issue. See > > e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1432484 (comment 30 > > has a workaround) > > Their bug tracker is down at the moment...
Yeah, planned intervention on it today. > Thanks. I know that SQLite is not ideal for NFS. We are using LizardFS which > performs better. We had our "/home" on LizardFS for years and apparently it > is good enough for Firefox which have many SQLite files in user's profiles. > > Of course file system congestion was the first thing I checked by moving > Firefox profile away from network file system... I don't remember the exact > numbers from the last time I've tried that but it felt like it doesn't matter > because even on local file system browser stopped responding for 30+ seconds > during loading of a page from tracker.debian.org. > > It doesn't make much sense when I think about it. Why would simple query to > client certificate, that does not modify "cert9.db" would cause I/O > congestion every time? Subsequent reads from that file would have been cached > yet every request is just as slow as the first one. It looks more and more > like a Firefox bug rather than pure issue with SQLite. > > > > > Once again, strangest thing is how much "tracker.debian.org" is affected > > > comparing to pretty much any other site. > > > > That's because tracker.debian.org, for some reason, asks for a > > client-side SSL certificate. > > Makes sense. Interesting. Perhaps I've accidentally exposed a problem in > Firefox with blocking processing of client certificates? Probably worth filing upstream, especially if you can reproduce with an upstream binary. Mike
