search for: lru_siz

...nu/glusterfs/6.10/xlator/features/shard.so(+0x21b47) [0x7fb261c13b47] -->/usr/lib/x86_64-linux-gnu/libglusterfs.so.0(inode_unref+0x36) [0x7fb26947f416] -->/usr/lib/x86_64-linux-gnu/libglusterfs.so.0(+0x3337a) [0x7fb26947f37a] ) 0-GLB1image-shard: Empty inode lru list found but with (-2) lru_size [2023-07-21 18:51:38.261231] W [inode.c:1638:inode_table_prune] (-->/usr/lib/x86_64-linux-gnu/glusterfs/6.10/xlator/mount/fuse.so(+0xba51) [0x7fb266cdca51] -->/usr/lib/x86_64-linux-gnu/libglusterfs.so.0(inode_unref+0x36) [0x7fb26947f416] -->/usr/lib/x86_64-linux-gnu/libglusterfs.so.0...

...nu/glusterfs/6.10/xlator/features/shard.so(+0x21b47) [0x7fb261c13b47] -->/usr/lib/x86_64-linux-gnu/libglusterfs.so.0(inode_unref+0x36) [0x7fb26947f416] -->/usr/lib/x86_64-linux-gnu/libglusterfs.so.0(+0x3337a) [0x7fb26947f37a] ) 0-GLB1image-shard: Empty inode lru list found but with (-2) lru_size [2023-07-21 18:51:38.261231] W [inode.c:1638:inode_table_prune] (-->/usr/lib/x86_64-linux-gnu/glusterfs/6.10/xlator/mount/fuse.so(+0xba51) [0x7fb266cdca51] -->/usr/lib/x86_64-linux-gnu/libglusterfs.so.0(inode_unref+0x36) [0x7fb26947f416] -->/usr/lib/x86_64-linux-gnu/libglusterfs.so.0...

...results: >>>> # grep itable <client-statedump> | grep active | wc -l >>>> # grep itable <client-statedump> | grep active_size >>>> # grep itable <client-statedump> | grep lru | wc -l >>>> # grep itable <client-statedump> | grep lru_size >>>> # grep itable <client-statedump> | grep purge | wc -l >>>> # grep itable <client-statedump> | grep purge_size >>>> >>> >>> Had to restart the test and have been running for 36 hours now. RSS is >>> currently up to 23g....

...he >>> results: >>> # grep itable <client-statedump> | grep active | wc -l >>> # grep itable <client-statedump> | grep active_size >>> # grep itable <client-statedump> | grep lru | wc -l >>> # grep itable <client-statedump> | grep lru_size >>> # grep itable <client-statedump> | grep purge | wc -l >>> # grep itable <client-statedump> | grep purge_size >> >> Had to restart the test and have been running for 36 hours now. RSS is >> currently up to 23g. >> >> Working on getting...

...wing query on statedump files and report us the results: > # grep itable <client-statedump> | grep active | wc -l > # grep itable <client-statedump> | grep active_size > # grep itable <client-statedump> | grep lru | wc -l > # grep itable <client-statedump> | grep lru_size > # grep itable <client-statedump> | grep purge | wc -l > # grep itable <client-statedump> | grep purge_size Had to restart the test and have been running for 36 hours now. RSS is currently up to 23g. Working on getting a bug report with link to the dumps. In the mean time, I...

...# grep itable <client-statedump> | grep active | wc -l > # grep itable <client-statedump> | grep active_size > # grep itable <client-statedump> | grep lru | wc -l > # grep itable <client-statedump> | grep lru_size > # grep itable <client-statedump> | grep purge | wc -l > # grep itable <client-statedump> | grep purge_size > > > Had to restart the test and have been running for 36 hours > now. RSS is > curre...

...and report us the > > results: > > # grep itable <client-statedump> | grep active | wc -l > > # grep itable <client-statedump> | grep active_size > > # grep itable <client-statedump> | grep lru | wc -l > > # grep itable <client-statedump> | grep lru_size > > # grep itable <client-statedump> | grep purge | wc -l > > # grep itable <client-statedump> | grep purge_size > > Had to restart the test and have been running for 36 hours now. RSS is > currently up to 23g. > > Working on getting a bug report with link...

...? # grep itable <client-statedump> | grep active | wc -l >> ??????????????? # grep itable <client-statedump> | grep active_size >> ??????????????? # grep itable <client-statedump> | grep lru | wc -l >> ??????????????? # grep itable <client-statedump> | grep lru_size >> ??????????????? # grep itable <client-statedump> | grep purge | wc -l >> ??????????????? # grep itable <client-statedump> | grep purge_size >> >> >> ??????????? Had to restart the test and have been running for 36 hours >> ??????????? now. RSS is...

...grep itable <client-statedump> | grep active | wc -l > > # grep itable <client-statedump> | grep active_size > > # grep itable <client-statedump> | grep lru | wc -l > > # grep itable <client-statedump> | grep lru_size > > # grep itable <client-statedump> | grep purge | wc -l > > # grep itable <client-statedump> | grep purge_size > > > > > > Had to restart the test and have been running for 36 hours > > now....

...Please run the following query on statedump files and report us the results: # grep itable <client-statedump> | grep active | wc -l # grep itable <client-statedump> | grep active_size # grep itable <client-statedump> | grep lru | wc -l # grep itable <client-statedump> | grep lru_size # grep itable <client-statedump> | grep purge | wc -l # grep itable <client-statedump> | grep purge_size > > I've CC'd the fuse/ dht devs to see if these data types have potential > leaks. Could you raise a bug with the volume info and a (dropbox?) link > from whi...

On 01/27/2018 02:29 AM, Dan Ragle wrote: > > On 1/25/2018 8:21 PM, Ravishankar N wrote: >> >> >> On 01/25/2018 11:04 PM, Dan Ragle wrote: >>> *sigh* trying again to correct formatting ... apologize for the >>> earlier mess. >>> >>> Having a memory issue with Gluster 3.12.4 and not sure how to >>> troubleshoot. I don't

We have been struggling with our Lustre performance for some time now especially with large directories. I recently did some informal benchmarking (on a live system so I know results are not scientifically valid) and noticed a huge drop in performance of reads(stat operations) past 20k files in a single directory. I''m using bonnie++, disabling IO testing (-s 0) and just creating, reading,