Re: memory usage (client)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Here are some more memory-usage data points:


client -> unify (alu) -> io-threads -> read-ahead -> write-behind:
 6697 root      15   0  369m 295m  876 S   45 14.6   3:10.13 [glusterfs]

client -> unify (alu) -> read-ahead -> write-behind:
 7218 root      17   0  476m 464m  844 R   85 23.0  41:15.20 [glusterfs]

client -> unify (alu) -> write-behind:
 8950 root      16   0  410m 398m  824 S   44 19.7   4:01.94 [glusterfs]

client -> unify (alu):
 9232 root      16   0  401m 389m  800 S   35 19.3   3:54.52 [glusterfs]

client -> unify (rr):
 9446 root      15   0  397m 385m  788 R   30 19.1   4:01.87 [glusterfs]

client (1)
 9744 root      16   0 66212  52m  696 S    3  2.6   3:32.37 [glusterfs]


Note that even the single-client glusterfs starts out very modestly
(with about 14m virt and 1.2m res).

We can safely rule out the performance xlators, as well as the
schedulers.

As we see, even a lone client seems to demonstrate a (small) memory leak.
Since I normally unify 4 volumes plus a namespace, that leak might be
multiplied by 5. I don't know for sure if that's enough to be
responsible on its own, or if there's also a leak in unify itself.

I hope that helps to narrow it down somewhat.


Rhesa


(1) the glusterfs client spec file for this run consisted of a single protocol/client volume, without any other xlators.




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux