[이현철]님이 남기신 글:
>-----------------------------------------
>답변자가 기본적으로 참고할 내용입니다.
>- 배포판(옵션) :
>- 커널버전(옵션)
:
>- 데몬버전(예:apache
1.3.27) :
>- 데몬설치유형(RPM/컴파일/기타)
:
>-----------------------------------------
>*중요:한글 문자가 하나도 없으면 스팸페이지로
이동합니다(스팸
필터링).
>
>몇칠째 끙끙 고민하다.. 산이님께.. 조언을 얻을수 밖에서
없었서.. 몇자 적습니다..
>
>몇칠전 부터 운영하고 있는 서버에 엄청 많은 접속량을 보이는
서버가 있습니다..
>
>현재 구조는 리눅스로 2대의 어플리케이션(앞으로
AP서버로 지칭하겠습니다.)
서버와(java) 그 밑단에 리눅스 DB서버 1대로(DB와 mysql)
연동되어 구성되어 있습니다. AP서버 2대는 로드밸렁싱을
이용한 (상용화 제품인F5 BIG-IP)를 통해 부하 부산 시스템형태로
구성되어 있습니다.
>
>AP서버는 외부에서 TCP프로토콜을 기반으로 해서 20010 포트를
이용해서 외부있는 각 점포의 클라이언트에서
정보를 받아들여 DB서버로 저장하고 형태입니다.
>
>
>현재 문제는 그번주 주말부터 엄청나게 많은 접속이
늘어나면서 (공격은 아닌것 같습니다 ) AP서버가 제대로
클라이언트에서
20010 포트로 제대로 접속할수 없는 형태로 보입니다.
>
>아래는 AP서버의 정보입니다.
>
>top - 20:39:51 up 4:00, 3 users, load average: 0.03, 0.02, 0.04
>Tasks: 69 total, 1 running, 68 sleeping, 0 stopped, 0 zombie
>Cpu0 : 0.0% us, 0.0% sy, 0.0% ni, 98.7% id, 1.0% wa, 0.0% hi, 0.3%
si
>Cpu1 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0%
si
>Cpu2 : 0.7% us, 0.3% sy, 0.0% ni, 99.0% id, 0.0% wa, 0.0% hi, 0.0%
si
>Cpu3 : 0.7% us, 0.0% sy, 0.0% ni, 99.3% id, 0.0% wa, 0.0% hi, 0.0%
si
>Mem: 2074668k total, 368216k used, 1706452k free, 33332k
buffers
>Swap: 2096472k total, 0k used, 2096472k free, 110968k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 7908 unitel 16 0 1474m 179m 8724 S 0.7 8.8 0:02.75 java
> 1 root 16 0 2788 544 464 S 0.0 0.0 0:00.83 init
>
>
>위의 내용을 보면 실제 cpu및 메모리 그리고 AP서버의 프로그램
java 보면 거의 서버자체의 부하는 없는것으로
보입니다.
>AP 서버 2대전부 위의 상황처럼 서버자체 부하는 거의 보이지
않는 상황입니다.
>
>load average 및 free 정보를 봐도 아주 조용한
형태입니다.
>[uel@log ~]$ uptime
> 20:42:53 up 4:03, 3 users, load average: 0.08, 0.05, 0.04
>[uel@log ~]$ free
> total used free shared buffers
cached
>Mem: 2074668 375752 1698916 0 33464
113436
>-/+ buffers/cache: 228852 1845816
>Swap: 2096472 0 2096472
>
>
>
>그런데 netstat를 보면
>아래는 20010접속에 대한 netstat내용의 일부분 입니다.
>[uel@log ]# netstat -na | grep :20010
>tcp 0 0 192.168.100.201:20010 122.29.249.88:61778
SYN_RECV
>tcp 0 0 192.168.100.201:20010 220.106.108.46:2136
SYN_RECV
>tcp 0 0 192.168.100.201:20010 211.17.38.85:2271
SYN_RECV
>tcp 0 0 192.168.100.201:20010 210.249.36.48:1580
SYN_RECV
>tcp 0 0 192.168.100.201:20010 59.139.22.193:63843
SYN_RECV
>tcp 0 0 192.168.100.201:20010 60.45.74.211:62265
SYN_RECV
>tcp 0 0 192.168.100.201:20010 61.214.132.156:1354
SYN_RECV
>tcp 0 0 192.168.100.201:20010 221.249.48.138:1297
SYN_RECV
>tcp 0 0 192.168.100.201:20010 60.236.29.40:10148
SYN_RECV
>tcp 0 0 192.168.100.201:20010 210.150.101.205:60368
SYN_RECV
>tcp 0 0 192.168.100.201:20010 211.129.222.171:1564
SYN_RECV
>tcp 0 0 192.168.100.201:20010 210.249.97.144:8527
SYN_RECV
>tcp 0 0 192.168.100.201:20010 221.252.164.226:1832
SYN_RECV
>tcp 0 0 192.168.100.201:20010 61.204.195.134:1408
SYN_RECV
>tcp 0 0 192.168.100.201:20010 222.149.211.36:18208
SYN_RECV
>tcp 0 0 :::20010 :::*
LISTEN
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:203.179.90.241:33859
ESTABLISHED
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:210.249.97.144:1105
ESTABLISHED
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:58.81.55.226:12287
ESTABLISHED
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:221.244.199.162:2795
ESTABLISHED
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:59.139.22.193:61474
ESTABLISHED
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:59.139.22.209:44850
ESTABLISHED
>
>----------------------- 생략 ------------------------------
>
> 20010 포트 의 액섹스 수는 아래와 같습니다.
>[uel@log ]# netstat -na |grep :20010 | wc -l
>80
>
>20010의 ESTABLISHED 수입니다.
>[uel@log]# netstat -na |grep :20010 | grep ESTABL | wc -l
>61
>
>[uel@log]# netstat -na |grep :20010 | grep SYN_RECV | wc -l
>20
>
>위와 같이 AP서버 2대가 거의 같은 SYN_RECV가 20 이상 계속
발생하고 있습니다.
>제가 알고 있는 syn_recv는 클라이언트에서
syn을 받고 나서 서버가 syn+ack를 클라이언트에 되돌려 준후에
클라이언트에서
ack가 올것이라는 것을 기다리는 half open상태로 알고
있습니다.
>
>이런 syn_recv가 많이 발생한다는것은
서비스거부공격
형태가 있다고 알고있습니다. 하지만 현재 ap서버에 발생하는
syn_recv의 클라이언트 ip는 실제 정상적인 클라이언트 아이피
입니다.. 이럴경우 syn_recv가 발생하는 원인이
무엇인지요?
>
>클라이언트에서
ACK가 오지 않는 이유를 모르겠습니다. .클라이언트 문제로
보이지는 않는데요..
>
>
>중간에 있는 로드밸렁싱이 제대로 처리를 못하는것이
문제인지. 시원한 답이 안나옵니다.. 로드밸렁싱 에서 보면
>반씩 커넥션수를 나누어 AP서버 2대에 나누어 주고 있습니다만.
외부에서 20010 포트에 대한 커넥션수가 동시접속수가 합계치가
200 정도의 이상의
>수치가 나오기도 합니다. 실제 AP서버 2대의 20010포트 접속수를
비교해보면 200커넥션 수가 나오지 않고 있는데요..
로드밸렁싱이 이상한것도 같기도 , 평소때는 보통 합쳐서
40커넥션 정도입니다만..
이번주 부터 이해하수없는 수치의 커넥션수가 발생하고
있습니다.
>
>하지만 그외 80,443 서비스 경우에는 부하부산 수치를
비교해보면 제대로 web서버와의 커넥션수와 일치하는것을
보면, 20010포트에 관한 실제 접속량이 많은것인지
의심스럽기도 합니다.
>
>데이타센터에서
제공해주는 회선 트랙픽 MRTG를 보면 트랙픽이 급격하게
발생하지는 않았습니다..조금
증간 한것을 볼수있지만. 한달전과 비교해 2배 이상
늘어나지도 않은 상황입니다...
>
>
>현재 외부에서 감시서버를 통해 20010를 감시하고 있습니다.만
경고메일이 1분 간격으로 20010포트가 접속이 되다가
안되다가를 반복하고 있습니다..
>실제 AP서버로 접속해서 telnet localhost 20010 형태로 local에서
확인해보면 커넥션이 접속되지 않다가 50초 후에 경우 접속 될
정도입니다.
>
>Syn_recv이랑 접속수의 상관관계가 있는지요? 접속량이
많을경우에 syn_recv가 발생하는것이 자연스럽운 현상인지
궁금합니다..
>
>
>tcpdump를 각 ap 서버와 로드밸렁싱 앞단에서 떠서 지금
분석중입니다만..
>
>마지막으로 netstat 결과를 보면 아래와 같이 ESTABLISHED 형태로
제대로 접속되 경우에도 Recv-Q를 보면 아직 처리하지 못한
바이트수가 있는
>ESTABLISHED 가 엄청 많이 존재하고 있습니다.
>이것도 문제인것 같습니다. 제 추측입니다만 넘겨주지 못한
패킷이 많다는것은 AP서버가 클라이언트에서
받아들인 패킷을 DB서버에 제대로 넘겨주지 못해서 인것
같은데요..
>
>--------------------------------------------------------------------
>[uel@log AP1]# netstat -ntp
>Active Internet connections (w/o servers)
>Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
>
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:210.233.5.10:1250
ESTABLISHED -
>tcp 81 0 ::ffff:192.168.100.20:20010 ::ffff:61.205.238.83:1392
ESTABLISHED 19123/java
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:221.244.61.82:2199
ESTABLISHED -
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:221.244.199.162:1377
ESTABLISHED -
>tcp 51 0 ::ffff:192.168.100.20:20010 ::ffff:61.118.149.124:44257
ESTABLISHED -
>:122.213.62.18:23368 ESTABLISHED -
>---------------------------------------------------------------------
>
>
>추가적으로 DB서버의 top 정보입니다.
>지금 확인 해보니 mysql 데몬의 cpu점유율이 엄청 많아
보입니다.
>load도 꽤 많이 높고요
>`-----------------------------------------------------
>top - 21:57:21 up 566 days, 6:44, 4 users, load average: 1.59, 1.52,
1.46
>Tasks: 110 total, 4 running, 106 sleeping, 0 stopped, 0 zombie
>Cpu0 : 34.6% us, 1.0% sy, 0.0% ni, 57.5% id, 7.0% wa, 0.0% hi, 0.0%
si
>Cpu1 : 96.0% us, 1.7% sy, 0.0% ni, 2.3% id, 0.0% wa, 0.0% hi, 0.0%
si
>Cpu2 : 0.3% us, 0.3% sy, 0.0% ni, 99.3% id, 0.0% wa, 0.0% hi, 0.0%
si
>Cpu3 : 85.4% us, 4.0% sy, 0.0% ni, 10.6% id, 0.0% wa, 0.0% hi, 0.0%
si
>Mem: 4086200k total, 4064732k used, 21468k free, 49584k
buffers
>Swap: 2096472k total, 13196k used, 2083276k free, 3467856k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 5429 mysql 17 0 443m 399m 3344 R 99.8 10.0 1393:28 mysqld
>22512 mysql 17 0 443m 399m 3344 R 73.5 10.0 54:15.82 mysqld
>22491 mysql 16 0 443m 399m 3344 R 49.6 10.0 46:00.56 mysqld
>23999 unitel 16 0 3220 960 752 R 0.7 0.0 0:00.04 top
>30390 root 15 0 22396 10m 2268 S 0.3 0.3 24:21.17 X
>-----------------------------------------------------------------
>
>
>
>DB서버의 mysql의 정보입니다.
>
>Queries per second avg: 79.808 이 내용 부분이 좀 걸리네요
>
>------------------------------------------------------------
>Connection Localhost via UNIX socket
>UNIX socket /tmp/mysql.sock
>Uptime: 294 days 11 hours 25 min 15 sec
>
>Threads: 12 Questions: 2030538121 Slow queries: 0 Opens: 0 Flush tables: 32
Open tables: 178 Queries per second avg: 79.808
>-------------------------------------------------------------
>
>
>mysql의 extended-status 정보입니다.
>+-----------------------------------+--------------+
>| Variable_name | Value |
>+-----------------------------------+--------------+
>| Aborted_clients | 14831 |
>| Aborted_connects | 53976 |
>| Binlog_cache_disk_use | 0 |
>| Binlog_cache_use | 0 |
>| Bytes_received | 4183154635 |
>| Bytes_sent | 4182490453 |
>| Com_admin_commands | 907105 |
>| Com_alter_db | 0 |
>| Com_alter_table | 25 |
>| Com_analyze | 3 |
>| Com_backup_table | 0 |
>| Com_begin | 0 |
>| Com_change_db | 766 |
>| Com_change_master | 0 |
>| Com_check | 9 |
>| Com_checksum | 0 |
>| Com_commit | 19 |
>| Com_create_db | 0 |
>| Com_create_function | 0 |
>| Com_create_index | 0 |
>| Com_create_table | 20217 |
>| Com_dealloc_sql | 0 |
>| Com_delete | 9457511 |
>| Com_delete_multi | 3 |
>| Com_do | 0 |
>| Com_drop_db | 0 |
>| Com_drop_function | 0 |
>| Com_drop_index | 0 |
>| Com_drop_table | 20218 |
>| Com_drop_user | 0 |
>| Com_execute_sql | 0 |
>| Com_flush | 31 |
>| Com_grant | 0 |
>| Com_ha_close | 0 |
>| Com_ha_open | 0 |
>| Com_ha_read | 0 |
>| Com_help | 0 |
>| Com_insert | 172890149 |
>| Com_insert_select | 857 |
>| Com_kill | 256 |
>| Com_load | 0 |
>| Com_load_master_data | 0 |
>| Com_load_master_table | 0 |
>| Com_lock_tables | 588 |
>| Com_optimize | 0 |
>| Com_preload_keys | 0 |
>| Com_prepare_sql | 0 |
>| Com_purge | 0 |
>| Com_purge_before_date | 0 |
>| Com_rename_table | 0 |
>| Com_repair | 8 |
>| Com_replace | 33657448 |
>| Com_replace_select | 42232 |
>| Com_reset | 0 |
>| Com_restore_table | 0 |
>| Com_revoke | 0 |
>| Com_revoke_all | 0 |
>| Com_rollback | 5 |
>| Com_savepoint | 0 |
>| Com_select | 198983161 |
>| Com_set_option | 36763 |
>| Com_show_binlog_events | 0 |
>| Com_show_binlogs | 0 |
>| Com_show_charsets | 0 |
>| Com_show_collations | 9019 |
>| Com_show_column_types | 0 |
>| Com_show_create_db | 0 |
>| Com_show_create_table | 5993 |
>| Com_show_databases | 148 |
>| Com_show_errors | 0 |
>| Com_show_fields | 6072 |
>| Com_show_grants | 0 |
>| Com_show_innodb_status | 0 |
>| Com_show_keys | 66 |
>| Com_show_logs | 0 |
>| Com_show_master_status | 5 |
>| Com_show_ndb_status | 0 |
>| Com_show_new_master | 0 |
>| Com_show_open_tables | 0 |
>| Com_show_privileges | 0 |
>| Com_show_processlist | 151637 |
>| Com_show_slave_hosts | 669 |
>| Com_show_slave_status | 1 |
>| Com_show_status | 7 |
>| Com_show_storage_engines | 0 |
>| Com_show_tables | 3381 |
>| Com_show_triggers | 5577 |
>| Com_show_variables | 9708 |
>| Com_show_warnings | 1 |
>| Com_slave_start | 0 |
>| Com_slave_stop | 0 |
>| Com_stmt_close | 40090696 |
>| Com_stmt_execute | 40107513 |
>| Com_stmt_fetch | 0 |
>| Com_stmt_prepare | 40099462 |
>| Com_stmt_reset | 0 |
>| Com_stmt_send_long_data | 0 |
>| Com_truncate | 0 |
>| Com_unlock_tables | 588 |
>| Com_update | 63499290 |
>| Com_update_multi | 5 |
>| Com_xa_commit | 0 |
>| Com_xa_end | 0 |
>| Com_xa_prepare | 0 |
>| Com_xa_recover | 0 |
>| Com_xa_rollback | 0 |
>| Com_xa_start | 0 |
>| Compression | OFF |
>| Connections | 65922 |
>| Created_tmp_disk_tables | 12041 |
>| Created_tmp_files | 147 |
>| Created_tmp_tables | 421243412 |
>| Delayed_errors | 0 |
>| Delayed_insert_threads | 0 |
>| Delayed_writes | 0 |
>| Flush_commands | 32 |
>| Handler_commit | 0 |
>| Handler_delete | 5131664 |
>| Handler_discover | 0 |
>| Handler_prepare | 0 |
>| Handler_read_first | 215559225 |
>| Handler_read_key | 110530486 |
>| Handler_read_next | 2452367653 |
>| Handler_read_prev | 0 |
>| Handler_read_rnd | 60148746 |
>| Handler_read_rnd_next | 3953640529 |
>| Handler_rollback | 0 |
>| Handler_savepoint | 0 |
>| Handler_savepoint_rollback | 0 |
>| Handler_update | 2052955131 |
>| Handler_write | 681769258 |
>| Innodb_buffer_pool_pages_data | 19 |
>| Innodb_buffer_pool_pages_dirty | 0 |
>| Innodb_buffer_pool_pages_flushed | 0 |
>| Innodb_buffer_pool_pages_free | 493 |
>| Innodb_buffer_pool_pages_latched | 0 |
>| Innodb_buffer_pool_pages_misc | 0 |
>| Innodb_buffer_pool_pages_total | 512 |
>| Innodb_buffer_pool_read_ahead_rnd | 1 |
>| Innodb_buffer_pool_read_ahead_seq | 0 |
>| Innodb_buffer_pool_read_requests | 77 |
>| Innodb_buffer_pool_reads | 12 |
>| Innodb_buffer_pool_wait_free | 0 |
>| Innodb_buffer_pool_write_requests | 0 |
>| Innodb_data_fsyncs | 3 |
>| Innodb_data_pending_fsyncs | 0 |
>| Innodb_data_pending_reads | 0 |
>| Innodb_data_pending_writes | 0 |
>| Innodb_data_read | 2494464 |
>| Innodb_data_reads | 25 |
>| Innodb_data_writes | 3 |
>| Innodb_data_written | 1536 |
>| Innodb_dblwr_pages_written | 0 |
>| Innodb_dblwr_writes | 0 |
>| Innodb_log_waits | 0 |
>| Innodb_log_write_requests | 0 |
>| Innodb_log_writes | 1 |
>| Innodb_os_log_fsyncs | 3 |
>| Innodb_os_log_pending_fsyncs | 0 |
>| Innodb_os_log_pending_writes | 0 |
>| Innodb_os_log_written | 512 |
>| Innodb_page_size | 16384 |
>| Innodb_pages_created | 0 |
>| Innodb_pages_read | 19 |
>| Innodb_pages_written | 0 |
>| Innodb_row_lock_current_waits | 0 |
>| Innodb_row_lock_time | 0 |
>| Innodb_row_lock_time_avg | 0 |
>| Innodb_row_lock_time_max | 0 |
>| Innodb_row_lock_waits | 0 |
>| Innodb_rows_deleted | 0 |
>| Innodb_rows_inserted | 0 |
>| Innodb_rows_read | 0 |
>| Innodb_rows_updated | 0 |
>| Key_blocks_not_flushed | 0 |
>| Key_blocks_unused | 0 |
>| Key_blocks_used | 334283 |
>| Key_read_requests | 213404926012 |
>| Key_reads | 4472707 |
>| Key_write_requests | 221195201 |
>| Key_writes | 109920190 |
>| Last_query_cost | 0.000000 |
>| Max_used_connections | 60 |
>| Not_flushed_delayed_rows | 0 |
>| Open_files | 236 |
>| Open_streams | 0 |
>| Open_tables | 178 |
>| Opened_tables | 41811 |
>| Qcache_free_blocks | 39 |
>| Qcache_free_memory | 16036752 |
>| Qcache_hits | 2628065 |
>| Qcache_inserts | 4028217 |
>| Qcache_lowmem_prunes | 0 |
>| Qcache_not_cached | 194965259 |
>| Qcache_queries_in_cache | 249 |
>| Qcache_total_blocks | 551 |
>| Questions | 2030539894 |
>| Rpl_status | NULL |
>| Select_full_join | 879262 |
>| Select_full_range_join | 379 |
>| Select_range | 11324395 |
>| Select_range_check | 2 |
>| Select_scan | 131812967 |
>| Slave_open_temp_tables | 0 |
>| Slave_retried_transactions | 0 |
>| Slave_running | OFF |
>| Slow_launch_threads | 0 |
>| Slow_queries | 1440 |
>| Sort_merge_passes | 351 |
>| Sort_range | 473 |
>| Sort_rows | 91476889 |
>| Sort_scan | 107289 |
>| Ssl_accept_renegotiates | 0 |
>| Ssl_accepts | 0 |
>| Ssl_callback_cache_hits | 0 |
>| Ssl_cipher | |
>| Ssl_cipher_list | |
>| Ssl_client_connects | 0 |
>| Ssl_connect_renegotiates | 0 |
>| Ssl_ctx_verify_depth | 0 |
>| Ssl_ctx_verify_mode | 0 |
>| Ssl_default_timeout | 0 |
>| Ssl_finished_accepts | 0 |
>| Ssl_finished_connects | 0 |
>| Ssl_session_cache_hits | 0 |
>| Ssl_session_cache_misses | 0 |
>| Ssl_session_cache_mode | NONE |
>| Ssl_session_cache_overflows | 0 |
>| Ssl_session_cache_size | 0 |
>| Ssl_session_cache_timeouts | 0 |
>| Ssl_sessions_reused | 0 |
>| Ssl_used_session_cache_entries | 0 |
>| Ssl_verify_depth | 0 |
>| Ssl_verify_mode | 0 |
>| Ssl_version | |
>| Table_locks_immediate | 1179431231 |
>| Table_locks_waited | 9485969 |
>| Tc_log_max_pages_used | 0 |
>| Tc_log_page_size | 0 |
>| Tc_log_page_waits | 0 |
>| Threads_cached | 3 |
>| Threads_connected | 12 |
>| Threads_created | 855 |
>| Threads_running | 5 |
>| Uptime | 25442788 |
>+-----------------------------------+--------------+
>
>
>여기저기 보고 해봐도 저 혼자서 해결이 좀 어려움이
많다보니. 산이님께 작은 조언이라도 해주시기
바랍니다..
>
>긴 내용 읽어 주셔서 감사합니다..
========================================
DB 서버, AP 서버 모두 이상이 없는것 같습니다. 외부의
공격이라고 단정지을만한 단서는 없구요.
문제는 AP 서버의 TCP 20010 포트를 사용하는 어플리케이션
문제인것 같습니다. 즉 이 어플리케이션이
대용량 커넥션 처리를 재대로 못하고 있는것 같습니다.
AP 서버에 ssh 접속해서 telnet 으로 다른 포트로 접속(연결)
테스트해보세요.
만약 다른 포트에 delay 없이 곧바로 연결되면 20010 포트를
사용하는 어플리케이션 문제가 확실합니다. <-- 이게
확실하다면 개발자에게 수정요청하세요.
그외에 클라이언트 점포가 정해진 IP 주소라면 이 IP 주소외에
모두 iptables 로 막는것이 좋습니다.
|
sun's longitude:219 03 29.91
/board/read.php:소스보기 
