Closed Bug 820753 Opened 13 years ago Closed 7 years ago

fsync of places.sqlite when title of page changes

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Version:
17 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: schuetzm, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [snappy])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 Build ID: 2012111600 Steps to reproduce: While programming, used the page title as convenient "debug output/progress indication" of a function that is repeatedly called by a timer. But the behaviour is probably the same when the page title is changed less frequently. Actual results: It seems on every change of the page title (e.g. by using jQuery $('title').text(...)) places.sqlite is updated. If this happens frequently, it creates a real storm of fsync()'s, causing excessive disk activity. Expected results: Either places.sqlite should not be updated on page title change (or only once in a minute), or fsync() should not be called on every change.
Forgot to add this is on openSUSE 12.2 x86_64, Firefox 17.0 as provided by openSUSE (MozillaFirefox-17.0-2.25.1.x86_64).
Component: Untriaged → Bookmarks & History
Whiteboard: [snappy]
I don't think we are insterested in optimizing the use-case of using title as an output vehicle, console.log exists for that. That said, it's highly unlikely we generate a bunch of fsyncs, since we use WAL journaling, the title change may at a maximum generate some write requests, and after many of these requests we may ask a single fsync.
Of course, changing <title> was just how I came across it. I'm going to make a test which strace to find out more about what's really happening, but the files named places.sqlite* are definitely updated (mtime changed).
The database is updated but you wrote that it causes frequent fsync. A fsync with every title update would be bad but a change places file is not a big issue.
If what you see updated is the places.sqlite-wal file, that's expected. We may even study some improvement to reduce the title changes traffic, but I'm not sure the added complication would be worth it, until we find some real life use-cases in the wild (like some frequently used website/webapp) that can't be solved differently. If you instead find something else, that will be interesting to investigate.
What I noticed was excessive disk activity when the script was running. I have now done the following test: ---------------------------------------- <html> <head> <title>xxx</title> <script type="text/javascript"> var i = 0; window.setInterval(function() { document.title = ""+i; i++; }, 10); </script> </head> <body> </body> </html> ---------------------------------------- # strace -f -p ... 2>&1 | grep sync [pid 1970] fsync(29 <unfinished ...> [pid 1970] <... fsync resumed> ) = 0 [pid 1970] fsync(29 <unfinished ...> [pid 1970] <... fsync resumed> ) = 0 [pid 1970] fsync(28 <unfinished ...> [pid 1970] <... fsync resumed> ) = 0 [pid 1970] fsync(29 <unfinished ...> This produced dozens of the above lines per second. fd's 28 and 29 are places.sqlite and places.sqlite-wal. When I increase the interval, the number of fsync's decreases. Then it can be seen that it's not really one fsync per title change, but maybe one every 10 changes. Indeed, I don't know of any cases in the wild. I think I've seen some pages use the title as a marquee-style news ticker, but this is probably too marginal a use case to merit any larger changes. But maybe a case could be made to argue that this behaviour can be used to trigger high disk activity as a kind of denial-of-service attack (or keeping some devices from entering power-save mode)?
To resolv this bug, the fsync should follow the browser.sessionstore.interval parameter. This bug hurts people: see http://superuser.com/questions/399473/firefox-writes-megabytes-of-data-per-minute-to-disk-why This bug is present in Firefox 24 too. Thanks!
bug 787755 is an example
Keywords: perf
An evident real life use-case, frequently used website, is: google maps. Search a place, for example California, and you get an url: https://www.google.com/maps/place/California,+USA/ then move the map, clicking with the mouse, and you get another url: https://www.google.com/maps/place/California,+USA/@39.6120433,-116.0184622,6z move again to get another url: https://www.google.com/maps/place/California,+USA/@35.1805508,-116.2381887,6z every new url launch one fsync() for places.sqlite and places.sqlite-wal. Also, even if this is not the intended use-case for title/url changes, it hurts users in the same way as unwanted pop-ups opening, that lead us the block pop-up windows feature. This bug is present in Firefox 31 too.
do you have a stack for the fsync call? As I said, WAL should never fsync, until it merges to the main database, that happens when the wal journal reaches at least 512KB. per https://www.sqlite.org/wal.html "Note that with PRAGMA synchronous set to NORMAL, the checkpoint is the only operation to issue an I/O barrier or sync operation (fsync() on unix or FlushFileBuffers() on windows)."
Due to usage of WAL we should not fsync every time, we may still look into reducing disk traffic when lots of changes happen, but that can happen elsewhere.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.