[Bug 894339] New: Firefox causes frequent disk fsync - systems slowness
https://bugzilla.novell.com/show_bug.cgi?id=894339 https://bugzilla.novell.com/show_bug.cgi?id=894339#c0 Summary: Firefox causes frequent disk fsync - systems slowness Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Firefox AssignedTo: bnc-team-mozilla@forge.provo.novell.com ReportedBy: klaussfreire@gmail.com QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Firefox, under some conditions, keeps updating its cache in /home/<user>/.firefox, and keeps updating its database there. The problem is that in doing so it keeps issuing frequent fsync calls, slowing down the whole system. iotop shows firefox [Cache I/O] and firefox [mozStorage #n] top users quite frequently (cache I/O more frequently than mozStorage). They're probably to blame that it also shows [jbd2/dm-n-n] very high in disk usage as well. Not sure which update or which page triggers it, but I've been keeping open facebook, youtube, slashdot, gmail and amazon's ec2 console. The system is using an LVM-based setup (hence the dm device), with root using ext3, and home using ext4. Both use options relatime,data=ordered. I'm not sure this is a firefox bug or a filesystem thing. It didn't use to happen a little while ago (seems to have come or gotten worse with some update, not sure which). Firefox is fsync-ing a file that seems to hold only a flag (perhaps a dirty flag), so it shouldn't be strainful on the filesystem (yet it is, apparently). Sample strace of the firefox [Cache I/O] process showing the fsync: futex(0x7f5f578727ac, FUTEX_WAIT_PRIVATE, 10969, NULL) = 0 futex(0x7f5f57872748, FUTEX_WAKE_PRIVATE, 1) = 0 lseek(48, 4694016, SEEK_SET) = 4694016 read(48, "\0\1\0\23\222\0G`\0\0\0\3T\3\230qT\2p\274T\f\255)\0\0b\211\0\0\0^"..., 768) = 768 futex(0x7f5f65f379bc, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f5f65f37958, 1902) = 1 write(23, "\372", 1) = 1 futex(0x7f5f578727ac, FUTEX_WAIT_PRIVATE, 10971, NULL) = 0 futex(0x7f5f57872748, FUTEX_WAKE_PRIVATE, 1) = 0 lseek(48, 4694016, SEEK_SET) = 4694016 write(48, "\0\1\0\23\222\0G`\0\0\0\4T\3\233\31T\2p\274T\f\255)\0\0b\211\0\0\0^"..., 579) = 579 lseek(45, 0, SEEK_SET) = 0 write(45, "0", 1) = 1 fsync(45) = 0 futex(0x7f5f578727ac, FUTEX_WAIT_PRIVATE, 10973, NULL) = 0 futex(0x7f5f57872748, FUTEX_WAKE_PRIVATE, 1) = 0 lseek(45, 0, SEEK_SET) = 0 write(45, "1", 1) = 1 fsync(45) = 0 Reproducible: Always Steps to Reproduce: 1. Launch firefox 2. Launch afforementioned pages (gmail, facebook, youtube, slashdot, amazon ec2 console if possible) 3. Wait for a while, let it build up on-disk changes 4. Do anything I/O-intensive, see how thoghput is notoriously decreased by keeping firefox open. Example: build something with make -j4 5. Shut down firefox, note it going back to normal. Actual Results: Low I/O thoughput on the fsync'd partition (home) Expected Results: Normal I/O thoughput on the fsync'd partition (home) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com