glusterfs.git/libglusterfs/src/statedump.c, branch v4.1.3

Revert "glusterfsd: Memleak in glusterfsd process while brick mux is on"

2018-05-25T02:05:37+00:00

Updates: bz#1582286
This reverts commit 7c3cc485054e4ede1efb358552135b432fb7047a.
Change-Id: I831d646112bcfa13d0c2153482ad00ff1b23aa6c
Signed-off-by: Mohit Agrawal

Revert "gluster: Sometimes Brick process is crashed at the time of stopping brick"

2018-05-25T02:05:37+00:00

Updates: bz#1582286
This reverts commit 0043c63f70776444f69667a4ef9596217ecb42b7.
Change-Id: Iab3b4f4a54e122c589e515add93c6effc966b3e0

gluster: Sometimes Brick process is crashed at the time of stopping brick

2018-04-19T04:31:51+00:00

Problem: Sometimes brick process is getting crashed at the time
         of stop brick while brick mux is enabled.

Solution: Brick process was getting crashed because of rpc connection
          was not cleaning properly while brick mux is enabled.In this patch
          after sending GF_EVENT_CLEANUP notification to xlator(server)
          waits for all rpc client connection destroy for specific xlator.Once rpc
          connections are destroyed in server_rpc_notify for all associated client
          for that brick then call xlator_mem_cleanup for for brick xlator as well as
          all child xlators.To avoid races at the time of cleanup introduce
          two new flags at each xlator cleanup_starting, call_cleanup.

BUG: 1544090
Signed-off-by: Mohit Agrawal 

Note: Run all test-cases in separate build (https://review.gluster.org/#/c/19700/)
      with same patch after enable brick mux forcefully, all test cases are
      passed.

Change-Id: Ic4ab9c128df282d146cf1135640281fcb31997bf
updates: bz#1544090

statedump: sanity check of mem_acct and rec for xlator

2018-01-31T13:05:42+00:00

With memory accounting is disabled, glusterfs crash when doing statedump at,

0  0x00007fe24cff543a in gf_proc_dump_xlator_mem_info_only_in_use (xl=0x7fe23e44dc00) at statedump.c:269
1  0x00007fe24cff6310 in gf_proc_dump_oldgraph_xlator_info (top=0x7fe23e44dc00) at statedump.c:530
2  0x00007fe24cff7114 in gf_proc_dump_info (signum=10, ctx=0x7fe24ac0e000) at statedump.c:845
3  0x00007fe24d4d4bab in glusterfs_sigwaiter (arg=0x7ffc6c080750) at glusterfsd.c:2109
4  0x00007fe24bbd5dc5 in start_thread () from /lib64/libpthread.so.0
5  0x00007fe24b51a73d in clone () from /lib64/libc.so.6

(gdb) p xl->mem_acct
$1 = (struct mem_acct *) 0x0
(gdb) p xl->mem_acct->rec
$2 = 0x10

Change-Id: I10858170431311833ae01224d51c66caaad5e9a3
BUG: 1539603
Signed-off-by: Kinglong Mee

mem-pool: count allocations done per user-pool

2017-08-29T19:14:04+00:00

Count the active allocations per 'struct mem_pool'. These are the
objects that the calling component allocated and free'd in the memory
pool for this specific type. Having this count in the statedump will
make it easy to find memory leaks.

Updates: #307
Change-Id: I797fabab86f104e49338c00e449a7d0b0d270004
Signed-off-by: Niels de Vos 
Reviewed-on: https://review.gluster.org/18074
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

mem-pool: track glusterfs_ctx_t in struct mem_pool

2017-08-29T12:37:40+00:00

In order to generate statedumps per glusterfs_ctx_t, it is needed to
place all the memory pools in a structure that the context can reach.
The 'struct mem_pool' has been extended with a 'list_head owner' that is
linked with the glusterfs_ctx_t->mempool_list.

All callers of mem_pool_new() have been updated to pass the current
glusterfs_ctx_t along. This context is needed to add the new memory pool
to the list and for grabbing the ctx->lock while updating the
glusterfs_ctx_t->mempool_list.

Updates: #307
Change-Id: Ia9384424d8d1630ef3efc9d5d523bf739c356c6e
Signed-off-by: Niels de Vos 
Reviewed-on: https://review.gluster.org/18075
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

statedump: add support for dumping basic mem-pool info

2017-08-28T12:40:33+00:00

With all the new 'struct mem_pool' infrastructure in place, it is now
possible to fetch details about the memory pools that a glusterfs_ctx_t
uses.

This only captures the information from 'struct mem_pool', and not from
the global 'struct mem_pool_shared' or the pool_sweeper thread. The
current details help with detecting memory leaks.

Updates: #307
Change-Id: Idbc5ba136df50863e1e380b448061509896f2c23
Signed-off-by: Niels de Vos 
Reviewed-on: https://review.gluster.org/18076
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Amar Tumballi

core: add more information on dictionary usage

2017-06-05T12:44:28+00:00

when you take the 'statedump', it shows the output like below

-----
[dict]
max-number-of-dict-pairs=13
total-pairs-used=41613
total-dict-used=12629
average-pairs-per-dict=3
------

Updates #220

Change-Id: I71a7eda3a3cd23edf4483234f22f983923bbb081
Signed-off-by: Amar Tumballi 
Reviewed-on: https://review.gluster.org/4035
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

libglusterfs: make memory pools more thread-friendly

2017-02-02T18:30:19+00:00

Early multiplexing tests revealed *massive* contention on certain
pools' global locks - especially for dictionaries and secondarily for
call stubs.  For the thread counts that multiplexing can create, a
more lock-free solution is clearly needed.  Also, the current mem-pool
implementation does a poor job releasing memory back to the system,
artificially inflating memory usage to match whatever the worst case
was since the process started.  This is bad in general, but especially
so for multiplexing where there are more pools and a major point of
the whole exercise is to reduce memory consumption.

The basic ideas for the new design are these

  There is one pool, globally, for each power-of-two size range.
  Every attempt to create a new pool within this range will instead
  add a reference to the existing pool.

  Instead of adding pools for each translator within each multiplexed
  brick (potentially infinite and quite possibly thousands), we
  allocate one set of size-based pools per *thread* (hundreds at
  worst).

  Each per-thread pool is divided into hot and cold lists.  Every
  allocation first attempts to use the hot list, then the cold list.
  When objects are freed, they always go on the hot list.

  There is one global "pool sweeper" thread, which periodically
  reclaims everything in each pool's cold list and then "demotes" the
  current hot list to be the new cold list.

  For normal allocation activity, only a per-thread lock need be
  taken, and even that only to guard against very rare contention from
  the pool sweeper.  When threads start and stop, a global lock must
  be taken to add them to the pool sweeper's list.  Lock contention is
  therefore extremely low, and the hot/cold lists also provide good
  locality.

A more complete explanation (of a similar earlier design) can be found
here:

 http://www.gluster.org/pipermail/gluster-devel/2016-October/051160.html

Change-Id: I5bc8a1ba57cfb553998f979a498886e0d006e665
BUG: 1385758
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/15645
Reviewed-by: Xavier Hernandez 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan

libglusterfs: fix glusterd statedump crash

2016-08-04T15:44:09+00:00

commit 3c04a91 removed setting typeStr to NULL if num_allocs is set to 0, this
has caused this regression. Code has been put back like earlier and to avoid
statedump printing all the NULL values check is modified to see skip the records
if num_allocs is 0 instead of total_allocs

Change-Id: Ib8bcc2fba908e88cf52b641c3f6bcba74f5e667c
BUG: 1359190
Signed-off-by: Atin Mukherjee 
Reviewed-on: http://review.gluster.org/14987
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: N Balachandran 
Reviewed-by: Prashanth Pai 
Reviewed-by: Jeff Darcy