I would suspect aggressive caching of some data describing every file
touched by the glusterfs client. In fact, these data seem to be kept forever,
as the memory is never freed and no new allocations are made, if the same
files are accessed for the second time. It is sufficient to run ls -R or du
> I hear you, I had followed this article specifically in an attempt to
> improve performance. I suppose I'm hoping for more specifics on how
> these values correspond to an application, a number of cpu's, a brand of
> network card, etc. io-threads counts, for example, only seem to drive
> lo
you could study the hints and configurations that MUST be tweaked for YOUR hw,
sw, network, and app behaviour.
It was used for php sessions for a groupware:
http://www.techforce.com.br/news/linux_blog/glusterfs_tuning_small_files
The client side and server caches, the flush periods, and io-threa
Please check the memory usage on the server and check if the swap space is
used much. You can try reducing the io-threads
count to 8 (in place of 16).
I had tried 16, 8, and 4 on io-threads. No swap usage at all.
John
--
John Madden
Sr UNIX Systems Engineer
Ivy Tech Community College of
For reading small files, you could try using Quick-read translator.
http://gluster.com/community/documentation/index.php/Translators/performance/quick-read
This was one of the caching options I explored but it didn't seem to help.
Also, keep in mind that it isn't just reading but lots of write
Hello,
you could study the hints and configurations that MUST be tweaked for YOUR hw,
sw, network, and app behaviour.
It was used for php sessions for a groupware:
http://www.techforce.com.br/news/linux_blog/glusterfs_tuning_small_files
The client side and server caches, the flush periods, and io-
er.org
Sent: Tuesday, December 8, 2009 10:54:44 AM GMT +05:30 Chennai, Kolkata,
Mumbai, New Delhi
Subject: Re: [Gluster-users] client-side cpu usage, performance issue
Hi John,
On Mon, Dec 7, 2009 at 8:20 PM, John Madden wrote:
>> For reading small files, you could try using Quick-read
Hi John,
On Mon, Dec 7, 2009 at 8:20 PM, John Madden wrote:
>> For reading small files, you could try using Quick-read translator.
>>
>>
>> http://gluster.com/community/documentation/index.php/Translators/performance/quick-read
>
> This was one of the caching options I explored but it didn't seem
Tejas N. Bhise wrote:
Thanks John. I just looked up the Horde website. Will download and
set it up. Meanwhile, any more details, besides the install, that you
think would help set this up in least amount of time would be
helpful, like, how to crank the incoming user rate etc. Such help
will enabl
PM GMT +05:30 Chennai, Kolkata, Mumbai,
New Delhi
Subject: Re: [Gluster-users] client-side cpu usage, performance issue
> Thank you for sharing information about you setup. Is the application
> you are using, something that we can easily setup and use for
> generating more diagnostics
Thank you for sharing information about you setup. Is the application
you are using, something that we can easily setup and use for
generating more diagnostics inhouse at Gluster ?
I suppose. It's Horde, a PHP-based groupware suite. I've got two
Apache nodes load-balanced using glusterfs as t
;
Cc: gluster-users@gluster.org
Sent: Monday, December 7, 2009 8:20:52 PM GMT +05:30 Chennai, Kolkata, Mumbai,
New Delhi
Subject: Re: [Gluster-users] client-side cpu usage, performance issue
> For reading small files, you could try using Quick-read translator.
>
> http://gluste
For reading small files, you could try using Quick-read translator.
http://gluster.com/community/documentation/index.php/Translators/performance/quick-read
This was one of the caching options I explored but it didn't seem to
help. Also, keep in mind that it isn't just reading but lots of writ
Hi John,
For reading small files, you could try using Quick-read translator.
http://gluster.com/community/documentation/index.php/Translators/performance/quick-read
Also we would like to know the GlusterFS version no used for this setup.
-
Anush
On Fri, Dec 4, 2009 at 3:40 AM, John Madden wro
I experienced some embarrassingly bad performance today from a two-node
AFR used by two clients to store and share PHP sessions. (I ended up
switching to NFS by the end of the day.) It was on average a few
thousand sessions with a good smattering of create/write/read with
pretty high concurren
15 matches
Mail list logo
