Hi Dmitry, On Tue, Oct 14, 2014 at 11:35:40AM +0200, Lukas Tribus wrote: > Hi Dmitry, > > > > > show pools after few days of uptime: > > Dumping pools usage. Use SIGQUIT to flush them. > > - Pool pipe (32 bytes) : 961 allocated (30752 bytes), 5 used, 3 users > > [SHARED] > > - Pool capture (64 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] > > - Pool channel (80 bytes) : 4136 allocated (330880 bytes), 648 used, 1 > > users [SHARED] > > - Pool task (112 bytes) : 3109 allocated (348208 bytes), 1367 used, 1 users > > [SHARED] > > - Pool uniqueid (128 bytes) : 0 allocated (0 bytes), 0 used, 1 users > > [SHARED] > > - Pool connection (320 bytes) : 2537 allocated (811840 bytes), 343 used, 1 > > users [SHARED] > > - Pool hdr_idx (416 bytes) : 2068 allocated (860288 bytes), 323 used, 1 > > users [SHARED] > > - Pool session (864 bytes) : 2068 allocated (1786752 bytes), 326 used, 1 > > users [SHARED] > > - Pool requri (1024 bytes) : 1491 allocated (1526784 bytes), 16 used, 1 > > users [SHARED] > > - Pool buffer (32800 bytes) : 4136 allocated (135660800 bytes), 648 used, 1 > > users [SHARED] > > Total: 10 pools, 141356304 bytes allocated, 22001680 used. > > Ok, this is after 4 days of uptime, correct? > > I would monitor this for another 5 - 10 days without reloading or SIGQUIT'ing > and > check the results then, to understand if the buffer allocations increase > linearly with > the uptime.
It simply looks to me that you've reached at least 2068 concurrent connections at least once (2 buffers per connection), which explains the 135 MB of buffers allocated with your 32kB buffers. Unfortunately I'm realizing that we don't have in the stats the maximum total number of connections reached, we only have it per frontend. But the fact that you reached about 4k sessions/s tends to validate this observation. Best regards, Willy
