언제나 소중한 답변 감사합니다.
개발자에게 일단 이야기 해서 프로그램쪽으로
확인중에 있습니다.
개인적으로 실력이 딸려서 그런지.. 논리적으로 개발자에게
납득시키는 점이 어렵네요..
감사합니다..좋은
하루되세요...
[산이]님이 남기신 글:
>
>[이현철]님이 남기신 글:
>
>>-----------------------------------------
>>답변자가 기본적으로 참고할 내용입니다.
>>- 배포판(옵션) :
>>- 커널버전(옵션)
:
>>- 데몬버전(예: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 로 막는것이 좋습니다.
========================================
|
오늘은 대한입니다.
/board/read.php:소스보기 
