posix_memalign error
Igor A. Ippolitov
iippolitov at nginx.com
Mon Aug 6 13:03:12 UTC 2018
Anoop,
I suppose, most of your 10k servers are very similar, right?
Please, post top level configuration and a typical server{}, please.
Also, how do you reload configuration? With 'service nginx reload' or
may be other commands?
It looks like you have a lot of fragmented memory and only 4gb free in
the second numa node.
So, I'd say this is OK that you are getting errors from allocating a 16k
stripes.
Could you please post numastat -m output additionally. Just to make sure
you have half of the memory for the second CPU.
And we'll have a look if memory utilization may be optimized based on
your configuration.
Regards,
Igor.
On 04.08.2018 07:54, Anoop Alias wrote:
> Hi Igor,
>
> Setting vm.max_map_count to 20x the normal value did not help
>
> The issue happens on a group of servers and among the group, it shows
> up only in servers which have ~10k server{} blocks
>
> On servers that have lower number of server{} blocks , the ENOMEM
> issue is not there
>
> Also, I can find that the RAM usage of the Nginx process is directly
> proportional to the number of server {} blocks
>
> For example on a server having the problem
>
> # ps_mem| head -1 && ps_mem |grep nginx
> Private + Shared = RAM used Program
> 1.0 GiB + 2.8 GiB = 3.8 GiB nginx (3)
>
>
> That is for a single worker process with 4 threads in thread_pool
> # pstree|grep nginx
> |-nginx-+-nginx---4*[{nginx}]
> | `-nginx
>
> Whatever config change I try the memory usage seem to mostly depend on
> the number of server contexts defined
>
> Now the issue mostly happen in nginx reload ,when one more worker
> process will be active in shutting down mode
>
> I believe the memalign error is thrown by the worker being shutdown,
> this is because the sites work after the error and also the pid
> mentioned in the error would have gone when I check ps
>
>
> # pmap 948965|grep 16K
> 00007f2923ff2000 16K r-x-- ngx_http_redis2_module.so
> 00007f2924fd7000 16K r---- libc-2.17.so <http://libc-2.17.so>
> 00007f2925431000 16K rw--- [ anon ]
> 00007f292584a000 16K rw--- [ anon ]
>
> Aug 4 05:50:00 b kernel: SysRq : Show Memory
> Aug 4 05:50:00 b kernel: Mem-Info:
> Aug 4 05:50:00 b kernel: active_anon:7757394 inactive_anon:1021319
> isolated_anon:0#012 active_file:3733324 inactive_file:2136476
> isolated_file:0#012 unevictable:0 dirty:1766 writeback:6 wbtmp:0
> unstable:0#012 slab_reclaimable:2003687 slab_unreclaimable:901391#012
> mapped:316734 shmem:2381810 pagetables:63163 bounce:0#012 free:4851283
> free_pcp:11332 free_cma:0
> Aug 4 05:50:00 bravo kernel: Node 0 DMA free:15888kB min:8kB low:8kB
> high:12kB active_anon:0kB inactive_anon:0kB active_file:0kB
> inactive_file:0kB unevictable:0kB isolated(anon):0kB
> isolated(file):0kB present:15972kB managed:15888kB mlocked:0kB
> dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB
> slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB
> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB
> pages_scanned:0 all_unreclaimable? yes
> Aug 4 05:50:00 b kernel: lowmem_reserve[]: 0 1679 64139 64139
>
> # cat /proc/buddyinfo
> Node 0, zone DMA 0 0 1 0 2 1 1
> 0 1 1 3
> Node 0, zone DMA32 5284 6753 6677 1083 410 59 1
> 0 0 0 0
> Node 0, zone Normal 500327 638958 406737 14690 872 106 11
> 0 0 0 0
> Node 1, zone Normal 584840 291640 188 0 0 0 0
> 0 0 0 0
>
>
> The only correlation I see in having the error is the number of
> server {} blocks (close to 10k) which then makes the nginx process
> consume ~ 4GB of mem with a single worker process and then a reload is
> done
>
>
>
>
> On Thu, Aug 2, 2018 at 6:02 PM Igor A. Ippolitov <iippolitov at nginx.com
> <mailto:iippolitov at nginx.com>> wrote:
>
> Anoop,
>
> There are two guesses: either mmap allocations limit is hit or
> memory is way too fragmented.
> Could you please track amount of mapped regions for a worker with
> pmap and amount of 16k areas in Normal zones (it is the third number)?
>
> You can also set vm.max_map_count to a higher number (like 20
> times higher than default) and look if the error is gone.
>
> Please, let me know if increasing vm.max_map_count helps you.
>
> On 02.08.2018 13:06, Anoop Alias wrote:
>> Hi Igor,
>>
>> The error happens randomly
>>
>> 2018/08/02 06:52:42 [emerg] 874514#874514: posix_memalign(16,
>> 16384) failed (12: Cannot allocate memory)
>> 2018/08/02 09:42:53 [emerg] 872996#872996: posix_memalign(16,
>> 16384) failed (12: Cannot allocate memory)
>> 2018/08/02 10:16:14 [emerg] 877611#877611: posix_memalign(16,
>> 16384) failed (12: Cannot allocate memory)
>> 2018/08/02 10:16:48 [emerg] 879410#879410: posix_memalign(16,
>> 16384) failed (12: Cannot allocate memory)
>> 2018/08/02 10:17:55 [emerg] 876563#876563: posix_memalign(16,
>> 16384) failed (12: Cannot allocate memory)
>> 2018/08/02 10:20:21 [emerg] 879263#879263: posix_memalign(16,
>> 16384) failed (12: Cannot allocate memory)
>> 2018/08/02 10:20:51 [emerg] 878991#878991: posix_memalign(16,
>> 16384) failed (12: Cannot allocate memory)
>>
>> # date
>> Thu Aug 2 10:58:48 BST 2018
>>
>> ------------------------------------------
>> # cat /proc/buddyinfo
>> Node 0, zone DMA 0 0 1 0 2 1
>> 1 0 1 1 3
>> Node 0, zone DMA32 11722 11057 4663 1647 609 72
>> 10 7 1 0 0
>> Node 0, zone Normal 755026 710760 398136 21462 1114 18
>> 1 0 0 0 0
>> Node 1, zone Normal 341295 801810 179604 256 0 0
>> 0 0 0 0 0
>> -----------------------------------------
>>
>>
>> slabinfo - version: 2.1
>> # name <active_objs> <num_objs> <objsize> <objperslab>
>> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> :
>> slabdata <active_slabs> <num_slabs> <sharedavail>
>> SCTPv6 21 21 1536 21 8 : tunables 0
>> 0 0 : slabdata 1 1 0
>> SCTP 0 0 1408 23 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> kcopyd_job 0 0 3312 9 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dm_uevent 0 0 2608 12 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> nf_conntrack_ffffffff81acbb00 14054 14892 320 51 4 :
>> tunables 0 0 0 : slabdata 292 292 0
>> lvp_cache 36 36 224 36 2 : tunables 0
>> 0 0 : slabdata 1 1 0
>> lve_struct 4140 4140 352 46 4 : tunables 0
>> 0 0 : slabdata 90 90 0
>> fat_inode_cache 0 0 744 44 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> fat_cache 0 0 40 102 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> isofs_inode_cache 0 0 664 49 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> ext4_inode_cache 30 30 1088 30 8 : tunables 0
>> 0 0 : slabdata 1 1 0
>> ext4_xattr 0 0 88 46 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> ext4_free_data 0 0 64 64 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> ext4_allocation_context 32 32 128 32 1 : tunables
>> 0 0 0 : slabdata 1 1 0
>> ext4_io_end 0 0 72 56 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> ext4_extent_status 102 102 40 102 1 : tunables 0
>> 0 0 : slabdata 1 1 0
>> jbd2_journal_handle 0 0 48 85 1 : tunables
>> 0 0 0 : slabdata 0 0 0
>> jbd2_journal_head 0 0 112 36 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> jbd2_revoke_table_s 256 256 16 256 1 : tunables
>> 0 0 0 : slabdata 1 1 0
>> jbd2_revoke_record_s 0 0 32 128 1 : tunables
>> 0 0 0 : slabdata 0 0 0
>> kvm_async_pf 0 0 136 30 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> kvm_vcpu 0 0 18560 1 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> xfs_dqtrx 992 992 528 31 4 : tunables 0
>> 0 0 : slabdata 32 32 0
>> xfs_dquot 3264 3264 472 34 4 : tunables 0
>> 0 0 : slabdata 96 96 0
>> xfs_ili 4342175 4774399 152 53 2 : tunables
>> 0 0 0 : slabdata 90083 90083 0
>> xfs_inode 4915588 5486076 1088 30 8 : tunables
>> 0 0 0 : slabdata 182871 182871 0
>> xfs_efd_item 2680 2760 400 40 4 : tunables 0
>> 0 0 : slabdata 69 69 0
>> xfs_da_state 1088 1088 480 34 4 : tunables 0
>> 0 0 : slabdata 32 32 0
>> xfs_btree_cur 1248 1248 208 39 2 : tunables 0
>> 0 0 : slabdata 32 32 0
>> xfs_log_ticket 14874 15048 184 44 2 : tunables 0
>> 0 0 : slabdata 342 342 0
>> xfs_ioend 12909 13104 104 39 1 : tunables 0
>> 0 0 : slabdata 336 336 0
>> scsi_cmd_cache 5400 5652 448 36 4 : tunables 0
>> 0 0 : slabdata 157 157 0
>> ve_struct 0 0 848 38 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> ip6_dst_cache 1152 1152 448 36 4 : tunables 0
>> 0 0 : slabdata 32 32 0
>> RAWv6 910 910 1216 26 8 : tunables 0
>> 0 0 : slabdata 35 35 0
>> UDPLITEv6 0 0 1216 26 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> UDPv6 832 832 1216 26 8 : tunables 0
>> 0 0 : slabdata 32 32 0
>> tw_sock_TCPv6 1152 1376 256 32 2 : tunables 0
>> 0 0 : slabdata 43 43 0
>> TCPv6 510 510 2176 15 8 : tunables 0
>> 0 0 : slabdata 34 34 0
>> cfq_queue 3698 5145 232 35 2 : tunables 0
>> 0 0 : slabdata 147 147 0
>> bsg_cmd 0 0 312 52 4 : tunables 0
>> 0 0 : slabdata 0 0 0
>> mqueue_inode_cache 136 136 960 34 8 : tunables 0
>> 0 0 : slabdata 4 4 0
>> hugetlbfs_inode_cache 1632 1632 632 51 8 : tunables
>> 0 0 0 : slabdata 32 32 0
>> configfs_dir_cache 1472 1472 88 46 1 : tunables 0
>> 0 0 : slabdata 32 32 0
>> dquot 0 0 256 32 2 : tunables 0
>> 0 0 : slabdata 0 0 0
>> userfaultfd_ctx_cache 32 32 128 32 1 : tunables
>> 0 0 0 : slabdata 1 1 0
>> fanotify_event_info 2336 2336 56 73 1 : tunables
>> 0 0 0 : slabdata 32 32 0
>> dio 6171 6222 640 51 8 : tunables 0
>> 0 0 : slabdata 122 122 0
>> pid_namespace 42 42 2192 14 8 : tunables 0
>> 0 0 : slabdata 3 3 0
>> posix_timers_cache 1056 1056 248 33 2 : tunables 0
>> 0 0 : slabdata 32 32 0
>> UDP-Lite 0 0 1088 30 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> flow_cache 2268 2296 144 28 1 : tunables 0
>> 0 0 : slabdata 82 82 0
>> xfrm_dst_cache 896 896 576 28 4 : tunables 0
>> 0 0 : slabdata 32 32 0
>> ip_fib_alias 2720 2720 48 85 1 : tunables 0
>> 0 0 : slabdata 32 32 0
>> RAW 3977 4224 1024 32 8 : tunables 0
>> 0 0 : slabdata 132 132 0
>> UDP 4110 4110 1088 30 8 : tunables 0
>> 0 0 : slabdata 137 137 0
>> tw_sock_TCP 4756 5216 256 32 2 : tunables 0
>> 0 0 : slabdata 163 163 0
>> TCP 2705 2768 1984 16 8 : tunables 0
>> 0 0 : slabdata 173 173 0
>> scsi_data_buffer 5440 5440 24 170 1 : tunables 0
>> 0 0 : slabdata 32 32 0
>> blkdev_queue 154 154 2208 14 8 : tunables 0
>> 0 0 : slabdata 11 11 0
>> blkdev_requests 4397688 4405884 384 42 4 : tunables
>> 0 0 0 : slabdata 104902 104902 0
>> blkdev_ioc 11232 11232 112 36 1 : tunables 0
>> 0 0 : slabdata 312 312 0
>> user_namespace 0 0 1304 25 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> sock_inode_cache 12282 12282 704 46 8 : tunables 0
>> 0 0 : slabdata 267 267 0
>> file_lock_cache 20056 20960 200 40 2 : tunables 0
>> 0 0 : slabdata 524 524 0
>> net_namespace 6 6 5056 6 8 : tunables 0
>> 0 0 : slabdata 1 1 0
>> shmem_inode_cache 16970 18952 712 46 8 : tunables 0
>> 0 0 : slabdata 412 412 0
>> Acpi-ParseExt 39491 40432 72 56 1 : tunables 0
>> 0 0 : slabdata 722 722 0
>> Acpi-State 1683 1683 80 51 1 : tunables 0
>> 0 0 : slabdata 33 33 0
>> Acpi-Namespace 11424 11424 40 102 1 : tunables 0
>> 0 0 : slabdata 112 112 0
>> task_delay_info 15336 15336 112 36 1 : tunables 0
>> 0 0 : slabdata 426 426 0
>> taskstats 1568 1568 328 49 4 : tunables 0
>> 0 0 : slabdata 32 32 0
>> proc_inode_cache 169897 190608 680 48 8 : tunables 0
>> 0 0 : slabdata 3971 3971 0
>> sigqueue 2208 2208 168 48 2 : tunables 0
>> 0 0 : slabdata 46 46 0
>> bdev_cache 792 792 896 36 8 : tunables 0
>> 0 0 : slabdata 22 22 0
>> sysfs_dir_cache 74698 74698 120 34 1 : tunables 0
>> 0 0 : slabdata 2197 2197 0
>> mnt_cache 163197 163424 256 32 2 : tunables 0
>> 0 0 : slabdata 5107 5107 0
>> filp 64607 97257 320 51 4 : tunables 0
>> 0 0 : slabdata 1907 1907 0
>> inode_cache 370744 370947 616 53 8 : tunables 0
>> 0 0 : slabdata 6999 6999 0
>> dentry 1316262 2139228 192 42 2 : tunables
>> 0 0 0 : slabdata 50934 50934 0
>> iint_cache 0 0 80 51 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> buffer_head 1441470 2890290 104 39 1 : tunables
>> 0 0 0 : slabdata 74110 74110 0
>> vm_area_struct 194998 196840 216 37 2 : tunables 0
>> 0 0 : slabdata 5320 5320 0
>> mm_struct 2679 2760 1600 20 8 : tunables 0
>> 0 0 : slabdata 138 138 0
>> files_cache 8680 8925 640 51 8 : tunables 0
>> 0 0 : slabdata 175 175 0
>> signal_cache 3691 3780 1152 28 8 : tunables 0
>> 0 0 : slabdata 135 135 0
>> sighand_cache 1950 2160 2112 15 8 : tunables 0
>> 0 0 : slabdata 144 144 0
>> task_xstate 8070 8658 832 39 8 : tunables 0
>> 0 0 : slabdata 222 222 0
>> task_struct 1913 2088 4080 8 8 : tunables 0
>> 0 0 : slabdata 261 261 0
>> cred_jar 31699 33936 192 42 2 : tunables 0
>> 0 0 : slabdata 808 808 0
>> anon_vma_chain 164026 168704 64 64 1 : tunables 0
>> 0 0 : slabdata 2636 2636 0
>> anon_vma 84104 84594 88 46 1 : tunables 0
>> 0 0 : slabdata 1839 1839 0
>> pid 11127 12576 128 32 1 : tunables 0
>> 0 0 : slabdata 393 393 0
>> shared_policy_node 9350 9350 48 85 1 : tunables 0
>> 0 0 : slabdata 110 110 0
>> numa_policy 62 62 264 31 2 : tunables 0
>> 0 0 : slabdata 2 2 0
>> radix_tree_node 771778 1194312 584 28 4 : tunables 0
>> 0 0 : slabdata 42654 42654 0
>> idr_layer_cache 2538 2565 2112 15 8 : tunables 0
>> 0 0 : slabdata 171 171 0
>> dma-kmalloc-8192 0 0 8192 4 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-4096 0 0 4096 8 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-2048 0 0 2048 16 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-1024 0 0 1024 32 8 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-512 0 0 512 32 4 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-256 0 0 256 32 2 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-128 0 0 128 32 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-64 0 0 64 64 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-32 0 0 32 128 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-16 0 0 16 256 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-8 0 0 8 512 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-192 0 0 192 42 2 : tunables 0
>> 0 0 : slabdata 0 0 0
>> dma-kmalloc-96 0 0 96 42 1 : tunables 0
>> 0 0 : slabdata 0 0 0
>> kmalloc-8192 385 388 8192 4 8 : tunables 0
>> 0 0 : slabdata 97 97 0
>> kmalloc-4096 9296 10088 4096 8 8 : tunables 0
>> 0 0 : slabdata 1261 1261 0
>> kmalloc-2048 65061 133536 2048 16 8 : tunables 0
>> 0 0 : slabdata 8346 8346 0
>> kmalloc-1024 11987 21120 1024 32 8 : tunables 0
>> 0 0 : slabdata 660 660 0
>> kmalloc-512 107510 187072 512 32 4 : tunables 0
>> 0 0 : slabdata 5846 5846 0
>> kmalloc-256 160498 199104 256 32 2 : tunables 0
>> 0 0 : slabdata 6222 6222 0
>> kmalloc-192 144975 237426 192 42 2 : tunables 0
>> 0 0 : slabdata 5653 5653 0
>> kmalloc-128 36799 108096 128 32 1 : tunables 0
>> 0 0 : slabdata 3378 3378 0
>> kmalloc-96 99510 238896 96 42 1 : tunables 0
>> 0 0 : slabdata 5688 5688 0
>> kmalloc-64 7978152 8593280 64 64 1 : tunables
>> 0 0 0 : slabdata 134270 134270 0
>> kmalloc-32 2939882 3089664 32 128 1 : tunables
>> 0 0 0 : slabdata 24138 24138 0
>> kmalloc-16 172057 172288 16 256 1 : tunables 0
>> 0 0 : slabdata 673 673 0
>> kmalloc-8 109568 109568 8 512 1 : tunables 0
>> 0 0 : slabdata 214 214 0
>> kmem_cache_node 893 896 64 64 1 : tunables 0
>> 0 0 : slabdata 14 14 0
>> kmem_cache 612 612 320 51 4 : tunables 0
>> 0 0 : slabdata 12 12 0
>>
>> -------------------------------------------------
>>
>>
>> # uname -r
>> 3.10.0-714.10.2.lve1.5.17.1.el7.x86_64
>>
>> --------------------------------------------------------
>>
>> Core part of glances
>> http://i.imgur.com/La5JbQn.png
>> -----------------------------------------------------------
>>
>> Thank you very much for looking into this
>>
>>
>> On Thu, Aug 2, 2018 at 12:37 PM Igor A. Ippolitov
>> <iippolitov at nginx.com <mailto:iippolitov at nginx.com>> wrote:
>>
>> Anoop,
>>
>> I doubt this will be the solution, but may we have a look at
>> /proc/buddyinfo and /proc/slabinfo the moment when nginx
>> can't allocate memory?
>>
>> On 02.08.2018 08:15, Anoop Alias wrote:
>>> Hi Maxim,
>>>
>>> I enabled debug and the memalign call is happening on nginx
>>> reloads and the ENOMEM happen sometimes on the reload(not on
>>> all reloads)
>>>
>>> 2018/08/02 05:59:08 [notice] 872052#872052: signal process
>>> started
>>> 2018/08/02 05:59:23 [notice] 871570#871570: signal 1
>>> (SIGHUP) received from 872052, reconfiguring
>>> 2018/08/02 05:59:23 [debug] 871570#871570: wake up, sigio 0
>>> 2018/08/02 05:59:23 [notice] 871570#871570: reconfiguring
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 0000000002B0DA00:16384 @16 === > the memalign call on
>>> reload
>>> 2018/08/02 05:59:23 [debug] 871570#871570: malloc:
>>> 00000000087924D0:4560
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 000000000E442E00:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: malloc:
>>> 0000000005650850:4096
>>> 20
>>>
>>>
>>>
>>>
>>> 2018/08/02 05:48:49 [debug] 871275#871275: bind() xxxx:443 #71
>>> 2018/08/02 05:48:49 [debug] 871275#871275: bind() xxxx:443 #72
>>> 2018/08/02 05:48:49 [debug] 871275#871275: bind() xxxx:443 #73
>>> 2018/08/02 05:48:49 [debug] 871275#871275: bind() xxxx:443 #74
>>> 2018/08/02 05:48:49 [debug] 871275#871275: add cleanup:
>>> 000000005340D728
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000024D3260:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000517BAF10:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 0000000053854FC0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 0000000053855FD0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 0000000053856FE0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 0000000053857FF0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: posix_memalign:
>>> 0000000053859000:16384 @16
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 000000005385D010:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 000000005385E020:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 000000005385F030:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536CD160:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536CE170:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536CF180:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D0190:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D11A0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D21B0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D31C0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D41D0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D51E0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D61F0:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D7200:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D8210:4096
>>> 2018/08/02 05:48:49 [debug] 871275#871275: malloc:
>>> 00000000536D9220:4096
>>>
>>>
>>> Infact there are lot of such calls during a reload
>>>
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA17ED00:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA1B0FF0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA1E12C0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA211590:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA243880:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA271B30:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA2A3E20:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA2D20D0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA3063E0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA334690:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA366980:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA396C50:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA3C8F40:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA3F9210:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA4294E0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA45B7D0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA489A80:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA4BBD70:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA4EA020:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA51E330:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA54C5E0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA57E8D0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA5AEBA0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA5DEE70:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA611160:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA641430:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA671700:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA6A29E0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA6D5CE0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA707FD0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA736280:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA768570:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA796820:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA7CAB30:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA7F8DE0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA82B0D0:16384 @16
>>> 2018/08/02 05:59:23 [debug] 871570#871570: posix_memalign:
>>> 00000000BA85B3A0:16384 @16
>>>
>>>
>>>
>>> What is perplexing is that the system has enough free
>>> (available RAM)
>>> #############
>>> # free -g
>>> total used free shared
>>> buff/cache available
>>> Mem: 125 54 24 8 46
>>> 58
>>> Swap: 0 0 0
>>> #############
>>>
>>> # ulimit -a
>>> core file size (blocks, -c) 0
>>> data seg size (kbytes, -d) unlimited
>>> scheduling priority (-e) 0
>>> file size (blocks, -f) unlimited
>>> pending signals (-i) 514579
>>> max locked memory (kbytes, -l) 64
>>> max memory size (kbytes, -m) unlimited
>>> open files (-n) 1024
>>> pipe size (512 bytes, -p) 8
>>> POSIX message queues (bytes, -q) 819200
>>> real-time priority (-r) 0
>>> stack size (kbytes, -s) 8192
>>> cpu time (seconds, -t) unlimited
>>> max user processes (-u) 514579
>>> virtual memory (kbytes, -v) unlimited
>>> file locks (-x) unlimited
>>>
>>> #########################################
>>>
>>> There is no other thing limiting memory allocation
>>>
>>> Any way to prevent this or probably identify/prevent this
>>>
>>>
>>> On Tue, Jul 31, 2018 at 7:08 PM Maxim Dounin
>>> <mdounin at mdounin.ru <mailto:mdounin at mdounin.ru>> wrote:
>>>
>>> Hello!
>>>
>>> On Tue, Jul 31, 2018 at 09:52:29AM +0530, Anoop Alias wrote:
>>>
>>> > I am repeatedly seeing errors like
>>> >
>>> > ######################
>>> > 2018/07/31 03:46:33 [emerg] 2854560#2854560:
>>> posix_memalign(16, 16384)
>>> > failed (12: Cannot allocate memory)
>>> > 2018/07/31 03:54:09 [emerg] 2890190#2890190:
>>> posix_memalign(16, 16384)
>>> > failed (12: Cannot allocate memory)
>>> > 2018/07/31 04:08:36 [emerg] 2939230#2939230:
>>> posix_memalign(16, 16384)
>>> > failed (12: Cannot allocate memory)
>>> > 2018/07/31 04:24:48 [emerg] 2992650#2992650:
>>> posix_memalign(16, 16384)
>>> > failed (12: Cannot allocate memory)
>>> > 2018/07/31 04:42:09 [emerg] 3053092#3053092:
>>> posix_memalign(16, 16384)
>>> > failed (12: Cannot allocate memory)
>>> > 2018/07/31 04:42:17 [emerg] 3053335#3053335:
>>> posix_memalign(16, 16384)
>>> > failed (12: Cannot allocate memory)
>>> > 2018/07/31 04:42:28 [emerg] 3053937#3053937:
>>> posix_memalign(16, 16384)
>>> > failed (12: Cannot allocate memory)
>>> > 2018/07/31 04:47:54 [emerg] 3070638#3070638:
>>> posix_memalign(16, 16384)
>>> > failed (12: Cannot allocate memory)
>>> > ####################
>>> >
>>> > on a few servers
>>> >
>>> > The servers have enough memory free and the swap usage
>>> is 0, yet somehow
>>> > the kernel denies the posix_memalign with ENOMEM (
>>> this is what I think is
>>> > happening!)
>>> >
>>> > The numbers requested are always 16, 16k . This makes
>>> me suspicious
>>> >
>>> > I have no setting in nginx.conf that reference a 16k
>>> >
>>> > Is there any chance of finding out what requests this
>>> and why this is not
>>> > fulfilled
>>>
>>> There are at least some buffers which default to 16k - for
>>> example, ssl_buffer_size
>>> (http://nginx.org/r/ssl_buffer_size).
>>>
>>> You may try debugging log to futher find out where the
>>> particular
>>> allocation happens, see here for details:
>>>
>>> http://nginx.org/en/docs/debugging_log.html
>>>
>>> But I don't really think it worth the effort. The error
>>> is pretty
>>> clear, and it's better to focus on why these allocations
>>> are
>>> denied. Likely you are hitting some limit.
>>>
>>> --
>>> Maxim Dounin
>>> http://mdounin.ru/
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org <mailto:nginx at nginx.org>
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>>
>>>
>>>
>>> --
>>> *Anoop P Alias*
>>>
>>>
>>>
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org <mailto:nginx at nginx.org>
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org <mailto:nginx at nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>>
>>
>> --
>> *Anoop P Alias*
>>
>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org <mailto:nginx at nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org <mailto:nginx at nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
>
> --
> *Anoop P Alias*
>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180806/31c0d52f/attachment-0001.html>
More information about the nginx
mailing list