Re: [Moosefs-users] fox and bird

[Steve W. <st...@pu...>]

On 05/11/2012 05:36 AM, Dr. Michael J. Chudobiak wrote:
> On 05/10/2012 05:28 PM, Steve Thompson wrote:
>> On Thu, 29 Mar 2012, Steve Thompson wrote:
>>
>>> I have further found that Thunderbird works well, but Firefox is so
>>> painfully slow (glacial) as to be unusable. For the time being, I have had
>>> to relocate the .mozilla directories to a non-MFS file system and replaced
>>> them by symbolic links.
> ...
>> Copying a large file into MFS gets me something like 80-85 MB/sec
>> (physically twice that with goal=2) so I am at a loss to explain the
>> dismal performance with firefox. I could really use some ideas, as I have
>> no idea where to go next.
> I would focus on the sqlite files that firefox uses. sqlite is notorious
> for causing problems on remote filesystems (particularly NFS).
> "urlclassifier3.sqlite" in particular grows to be very large (~64 MB).
>
> Are the fsync times reported by mfs.cgi (under "disks") OK? Some apps
> call fsync much more frequently than others.
>
> - Mike

I've been chasing similar problems the past day or two and have found 
that the sqlite files created by Firefox to be a real problem (e.g., 
cookies.sqlite-wal, cookies.sqlite-shm, urlclassifier3.sqlite, 
places.sqlite-wal).  Also, I've had occasional problems with a user's 
~/.xsession-errors causing a lot of I/O activity.  Notice the number of 
messages sent (and dropped) to syslog:

    May 11 10:00:37 maverick mfsmount[4749]: file: 75074, index: 3 -
    fs_writechunk returns status 11
    May 11 10:00:38  mfsmount[4749]: last message repeated 199 times
    May 11 10:00:38 maverick rsyslogd-2177: imuxsock begins to drop
    messages from pid 4749 due to rate-limiting
    May 11 10:00:39 maverick mfschunkserver[2437]: testing chunk:
    /mfs/01/C2/chunk_00000000000F4DC2_00000001.mfs
    May 11 10:00:44 maverick rsyslogd-2177: imuxsock lost 17465 messages
    from pid 4749 due to rate-limiting

Additionally, gvfsd-metadata has problems using shared network storage 
(I think it creates a memory mapped file).  I finally removed the 
execute bit from the gvfsd-metadata permissions to prevent from 
running.  This solved a problem I had with very high chunk deletion 
dramatically slowing down the MFS storage system.

In each of these cases, it's not the fault of MooseFS but applications 
that don't properly handle network storage systems.

Steve