사진부터 시작하겠습니다.
이는 백업 Tomcat 서버의 메모리 사용량입니다. 그것은 단지 거기에 매달려서 몇 초마다 간단한 상태 확인 요청을 처리하고 주 서버의 충돌이 부하를 받기를 기다리고 있습니다. 그리고 여전히 메모리 사용량이 증가하고 있습니다. 메인 서버의 메모리도 동일하게 증가합니다. 그리고 조만간 Nagios는 메모리 및 스왑 사용에 대한 스팸 SMS와 이메일을 보내기 시작합니다.
두 서버 모두 CentOS 7, 커널 3.10, Java 1.7 및 Tomcat 7을 실행하고 있습니다.
을 사용하여 Tomcat 서버를 중지하더라도 systemctl stop tomcat메모리는 계속 사용됩니다.
메모리를 해제하는 유일한 방법은 sync && echo 3 > /proc/sys/vm/drop_caches. 따라서 해결 방법은 이것을 cronjob. 하지만 적절한 해결책을 찾고 싶습니다.
나는 이것을 찾았다실비슷한 문제에 대해 4로 설정(및 다른 스레드 조언은 1로 설정)에 대해 언급 하고 환경 변수 MALLOC_ARENA_MAX와 함께 작동해야 한다는 스레드도 발견했습니다 . MALLOC_CHECK_그러나 그렇지 않습니다. 이것이 차트의 오른쪽 부분에서 볼 수 있는 것입니다.
내가 광고를 보면사용된 메모리, 약 600MB를 유지하며힙이 아닌 메모리 사용70MB입니다.
이 문제의 원인과 해결 방법을 알고 계시나요? 그리고 반복합니다. Tomcat이 중지된 후에도 메모리가 해제되지 않으므로 우리 앱에서 메모리가 누출된다고는 생각하지 않습니다.
# free -m
total used free shared buffers cached
Mem: 64268 4960 59307 64 0 135
-/+ buffers/cache: 4824 59443
Swap: 2047 0 2047
# ps -eo rss | awk '{sum += $1}; END {print sum/1024/1024}'
2.54199
cronjob이 메모리를 해제한 지 9시간이 지난 오늘 아침부터 업데이트됩니다.
# free -h
total used free shared buffers cached
Mem: 62G 13G 48G 80M 0B 77M
-/+ buffers/cache: 13G 48G
Swap: 2,0G 4K 2,0G
# ps -eo vsize | awk '{sum += $1}; END {print sum/1024/1024}'
25.8389
# ps -eo rss | awk '{sum += $1}; END {print sum/1024/1024}'
1.24232
# ps -eo pmem,rss,vsize,args | grep tomcat
1.7 1158608 22684408 java -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start
정말 이상해지고 있어요. 몇 초 keepalived마다 앱의 상태 확인 기능에 HTTP 요청을 계속 보내는 실행이 있습니다 . curl을 중지하면 keepalived메모리 증가가 중지됩니다. curl동일한 시스템의 bash에서 동일한 요청을 무한 루프로 보내면 메모리가 다시 커지기 시작합니다. 404를 반환하는 URL로 요청을 보내더라도. 다른 컴퓨터에서(즉, localhost가 아닌) 동일한 루프를 시작하면 메모리는 괜찮습니다.
# slabtop -o
Active / Total Objects (% used) : 244359165 / 244369016 (100,0%)
Active / Total Slabs (% used) : 5810996 / 5810996 (100,0%)
Active / Total Caches (% used) : 70 / 99 (70,7%)
Active / Total Size (% used) : 45770306,72K / 45772288,52K (100,0%)
Minimum / Average / Maximum Object : 0,01K / 0,19K / 8,00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
243660018 243660018 11% 0,19K 5801429 42 46411432K dentry
143872 141868 98% 0,03K 1124 128 4496K kmalloc-32
118150 118150 100% 0,02K 695 170 2780K fsnotify_event_holder
87040 87040 100% 0,01K 170 512 680K kmalloc-8
80448 79173 98% 0,06K 1257 64 5028K kmalloc-64
56832 56832 100% 0,02K 222 256 888K kmalloc-16
31926 31926 100% 0,08K 626 51 2504K selinux_inode_security
31140 31140 100% 0,11K 865 36 3460K sysfs_dir_cache
15795 14253 90% 0,10K 405 39 1620K buffer_head
15008 14878 99% 1,00K 469 32 15008K xfs_inode
14616 13365 91% 0,19K 348 42 2784K kmalloc-192
11961 11714 97% 0,58K 443 27 7088K inode_cache
10048 9108 90% 0,06K 157 64 628K anon_vma
9664 9480 98% 0,12K 302 32 1208K kmalloc-128
9287 7954 85% 0,21K 251 37 2008K vm_area_struct
8624 8624 100% 0,07K 154 56 616K Acpi-ParseExt
7264 7063 97% 0,25K 227 32 1816K kmalloc-256
5908 5908 100% 0,57K 211 28 3376K radix_tree_node
5304 5304 100% 0,04K 52 102 208K Acpi-Namespace
4620 4620 100% 0,09K 110 42 440K kmalloc-96
3744 3586 95% 1,00K 117 32 3744K kmalloc-1024
3458 3458 100% 0,30K 133 26 1064K nf_conntrack_ffffffff819a29c0
3360 3067 91% 0,50K 105 32 1680K kmalloc-512
3108 3108 100% 0,38K 74 42 1184K blkdev_requests
2975 2975 100% 0,05K 35 85 140K shared_policy_node
2520 2368 93% 0,64K 105 24 1680K proc_inode_cache
1560 1560 100% 0,81K 40 39 1280K task_xstate
1300 1300 100% 0,15K 50 26 200K xfs_ili
1272 1272 100% 0,66K 53 24 848K shmem_inode_cache
1176 1176 100% 1,12K 42 28 1344K signal_cache
1024 1024 100% 2,00K 64 16 2048K kmalloc-2048
975 975 100% 0,62K 39 25 624K sock_inode_cache
900 900 100% 0,44K 25 36 400K scsi_cmd_cache
864 864 100% 0,25K 27 32 216K tw_sock_TCPv6
737 644 87% 2,84K 67 11 2144K task_struct
720 672 93% 2,00K 45 16 1440K TCPv6
704 704 100% 0,18K 16 44 128K xfs_log_ticket
665 665 100% 0,23K 19 35 152K cfq_queue
646 646 100% 0,94K 19 34 608K RAW
640 640 100% 0,39K 16 40 256K xfs_efd_item
624 624 100% 0,10K 16 39 64K blkdev_ioc
624 624 100% 0,20K 16 39 128K xfs_btree_cur
578 578 100% 0,12K 17 34 68K fsnotify_event
555 555 100% 2,06K 37 15 1184K sighand_cache
528 528 100% 0,48K 16 33 256K xfs_da_state
512 512 100% 0,06K 8 64 32K kmem_cache_node
512 512 100% 1,00K 16 32 512K UDP
465 465 100% 2,06K 31 15 992K idr_layer_cache
450 450 100% 0,62K 18 25 288K files_cache
답변1
출력 에 따르면 slabtop무언가가 어딘가에 많은 임시 파일을 추가한 다음 삭제하고 있다고 말하고 싶습니다. 추가 트위스트는 일부 프로세스가 여전히 삭제된 파일에 대한 파일 핸들을 보유하고 있어 파일이 덴트리에서 해제되지 않는다는 것입니다. 파일은 삭제된 것으로 표시되므로 일반 ls명령이나 유사한 명령 으로는 찾을 수 없습니다 .
컬이거나 호출하는 스크립트일 수 있습니다. lsof -n | grep deleted삭제된 항목이 많이 있는지 확인 하고 거기에서 범인을 추적하세요.