안녕Ȣ16;1;니까, 맨DŽ16; 1656;문만 올리lj16; 왜국서 1068;Ȣ16;lj16; 무1648;1;1060;1077;니다. (__)
1656;문드릴 내용1008;
스위치1032; 성능1060; 떨Ǻ12;1648;면 보내lj16; 패ᓟ1;에 1648;연1060; 1068;Ǻ12;DŽ16; 수 1080;lj16;1648; 알고 dz10;습니다.
요1204;번에 5000ms 1648;연1060; 1068;Ǻ12;DŽ12;다고 올린 1201;1060; 1080;습니다만,
열심7176; 확1064;해보니  
상위1204;화서버 -> 운영1473;1064;서버 (1221;상) -> 운영1473;1064;서버 -> Ȣ16;위서버(비1221;상 5000ms 1648;연0156;생) 
1060;더군요
Ǽ12;1901;1060; 0155;1008; 패ᓟ1;1060;고 오른1901;1060; 보낸 패ᓟ1; 1077;니다.
Asterisk/196; 운영1473;1064; 서버고요, 단순7176; SIP / RTP 패ᓟ1;1012; 1116;1204;송Ȣ16;lj16; 용도/196; 사용Ȣ16;고 1080;습니다.
0155;1008;,152; 다시 보내기만 Ȣ16;lj16; ,163;1060;1648;요 (상위 사업1088; 1228;한사항1060;라 1060;/111;,172; 사용Ȣ16;고 1080;습니다.)
서버 사용률1008; 낮았lj16;데 (CPU 1060;용률 10%0120;만)
1200;/111;,172; .104;lj16; 1060;유를 모르,192;습니다.
스위치가 넷기Ǻ12;1032; 8포트1676;리라서 그1901;1012; 1032;심Ȣ16;고 1080;습니다만
스위치가 Ǻ12;떤 상태1060;,148; 서버에서 UDP/196; 송신Ȣ16;lj16;데 패ᓟ1;캡쳐상 1648;연1060; 1068;Ǻ12;DŽ12;다lj16;,172; 1060;해가 가1656; 않습니다.
(서버가 12대1064;데 8포트 + 8포트 구성1077;니다. 1200;런 ,152; 넣Ǻ12; .164; 1204;1076;1088;와 GMO 영업1012; ǐ12;리고 dz10;습니다.)
ᕬ1;시 스위치가 보내lj16; 패ᓟ1;에 그,163;도 서버에서 송신Ȣ16;lj16; 패ᓟ1;에 1648;연1012; 1068;1004;킬 수 1080;lj16;1648;요?
아무1900;/197; 가르침1012; ǥ12;ᓠ1;드립니다.
감사합니다.
재전송이 아닌, 원래 패킷이 5초 지연되어 들어가나요?
일단 패킷 캡쳐상에서 seq가 연속되고 있기도 하고요
혹시 더미허브(논메니지먼트 허브)급인가요??
재대로 확인할려면 포트 모니터링 장비 붙여서 패킷로스 확인해보는 편이 좋아 보입니다..
그 외 조심할 것은 케이블의 품질입니다..
전임자에게 물어보니 초기비용 몇만원 아끼려고 24포트가 아니라 8포트 붙였다는데
인터넷은 전용선을 깔아놨고요...
경영진도 그렇고 제정신이 아니었던 것 같습니다.
100 mbps 스위치가 아닌지 체크
일단 링크는 기가빗으로 나오네요
월요일에 업체 영업 담당에게 문의넣었는데
문의 폼으로 연락하라더니 아직까지 연락이 없네요.
그런데, 5ms도 아니고 5sec는 스위치문제로 생긴 지연이라고 보기에는 너무 과도합니다.
지금 캡쳐를 서버에서 하셨으니 보내고 받은 시점 역시 서버의 시간이고, 그렇다면 저 지연은 스위치가 아니라 서버에서 발생한거라고 보는게 타당한 것으로 사료됩니다.
서버 message log나 어플리케이션(asterisk)등 에서는 해당 시간대에 특별히 에러나 워닝 같은게 안보여서 원인을 찾는데 시간이 걸리고 있습니다.
따로 원인을 확인할 방법이 있을런지요?
(하드 배드 등으로 데이터가 재대로 못날라가고 지연되는 경우)
어느 서버에서 데이터 오류나 지연이 생기는지부터 확인하세요.. (여러 서버인지 그 서버 하나인지)
하위서버는 pbx입니다만 하위서버에 udp로 보내는 저래서 하위서버와는 무관하게 발생하는게 아닐까 생각하고 있습니다.
HDD 오류라면 뭘로 검사하는게 좋을지요?
부끄럽게도 아직도 리눅스(centos6 입니다)를 잘 모릅니다.
fsck를 쓰게되면 데이터가 다 날아간다고 절대 쓰지말라고 전임자에게 배웠는데 제 자신이 무지해서 무섭네요...
처음 리눅스 배울 때 꽤나 소리를 들어서요... ㅎ
(채크하다 서비스 끊어지면 골치)
하드에서 S.M.A.R.T 채크라는 것이 있는데 리눅스 명령어 중에 이것을 채크할 수 있다면 이 내용으로 하드의 건강상태를 짐작할 수 있습니다..
저도 리눅스는 거의 모르기에....
찾아보겠습니다 ㅎㅎ
fsck는 보통 논리적인 오류(파일시스템이나 볼륨의 메타데이터 정보 불일치 등)을 검사할 때 씁니다.
SMART 검사는 smartctl -t long /dev/sdX 같은 형태로 검사하시면 되고요,
이건 하드디스크 펌웨어에서 검사를 하는 것이기 때문에, 시스템이 크게 느려지거나 하는 문제는 없습니다.
그리고 정말 디스크 자체의 문제를 파악할 수 있습니다.
badblocks 는 OS 위에서 디스크를 읽으면서 테스트하는 것이기 때문에 다른 프로세스의 IO에 영향이 있을 수 있습니다.
디스크는 문제가 없지만, 케이블이 문제가 있다거나, SATA컨트롤러가 문제가 있다거나 하는 경우에는
SMART오류는 없는데, 실제 읽기 테스트를 할 때 문제를 발견하게 됩니다.
그리고 데이터를 읽을 때 오류가 발생해야만 문제라고 보는 것이 아니고,
오류가 없다고 하더라도 전송속도가 너무 느리거나, io wait가 높게 나오는 것도 문제가 있다고 봐야합니다.
그리고 fsck로 검사를 하다가 데이터를 날린다는 이야기는,
검사를 하는 것 자체는 문제가 없지만, fsck가 오류를 발견했을 때 수정을 시도하면서 문제가 발생하는 경우가 있습니다.
그게 OS 파티션이고, 마운트되어서 현재 사용중인 파티션이면 오류를 수정하면서 운나쁘게도 시스템이 다운될수도 있는 것이지요.
그리고 제 생각에도 윗분들 말씀처럼 스위치보다는 서버 문제일 가능성을 고려해보시는 것이 좋겠네요.
IO wait가 심하게 높은 경우에는 OS 커널 쪽에서 제때제때 IO 명령을 못 받아줄 수가 있는데요,
사용중인 디스크에 문제가 있거나 컨트롤러에 문제가 발생하면 그런 경우가 있을 수 있습니다.
일시적으로 시스템이 행이 걸렸다가 풀렸다가 하는거죠.
서버에서 SSD를 사용하는데 용량을 거의 풀로 사용하면서 프리징이 걸렸다 풀렸다 하면서 네트웍도 끊어졌다 붙었다 하는 그런 경우도 있었구요.
그리고 모든 경로를 다 확인해보셨는지요?
올려주신 그림에 reverse 방향의 delta는 올려주지 않아서요.
- 상위서버 -> 운영서버: 상위서버와 운영서버 양쪽에서 패킷 캡쳐해서 비교. 보통은 불가능해서 운영서버에서만 확인하죠.
- 상위서버 <- 운영서버: 상동
- 운영서버 -> 하위서버: 운영서버와 하위서버 양쪽에서 패킷 캡쳐해서 비교. (올리신게 하위서버에서 확인한 패킷을 올리신 것 같은데 맞나요?)
- 운영서버 <- 하위서버: 상동
제가 겪은 경우인데요, 고객사에서 제공한 IDC상면에 서버를 넣었는데 네트웍 대역폭이 부족해서 비슷한 상황이 발생한 적이 있습니다.
IDC의 서버들이 shared 네트웍을 사용하는데 장애발생 당시 고객사에서 배치로 파일전송을 하면서 (그것도 한낮에!!!) 대역폭을 몽땅 사용하고 있어서......
그냥 하루만 그랬으면 넘어갔을텐데 그분들이 뭘 잘못 만들었는지 일주일정도 계속 낮에 배치를 수동으로 돌리는 바람에 ㅋㅋㅋ
IDC랑 우리랑 계약한것도 아니니 대역폭 꽉 차서 장애나는건 우리는 모르고 고객사 담당자가 바뀌었는데 연락처 갱신을 안해서 고객사에서도 모르고 있었고...
고객사 사람이랑 같이 IDC들어가서 확인해보고 알았죠.