송주환 2018-10

그렇다 해도 5초 지연은 좀 심한데요. 버퍼 사이즈가 5초 지연을 일으킬 수준이 아니다 보니.
재전송이 아닌, 원래 패킷이 5초 지연되어 들어가나요?

dragoune 2018-10

전화용이라서 UDP로 RTP를 보내다보니 재전송이라는 개념이 없다고 생각 됩니다.
일단 패킷 캡쳐상에서 seq가 연속되고 있기도 하고요

박문형 2018-10

넷기어 8포트 모델이 몬가요??

혹시 더미허브(논메니지먼트 허브)급인가요??

재대로 확인할려면 포트 모니터링 장비 붙여서 패킷로스 확인해보는 편이 좋아 보입니다..

그 외 조심할 것은 케이블의 품질입니다..

dragoune 2018-10

GMO쪽에서 정확한 장비명을 공개할 수 없다고 해서 잘은 모릅니다.
전임자에게 물어보니 초기비용 몇만원 아끼려고 24포트가 아니라 8포트 붙였다는데
인터넷은 전용선을 깔아놨고요...

경영진도 그렇고 제정신이 아니었던 것 같습니다.

회원K 2018-10

cable 점검
100 mbps 스위치가 아닌지 체크

dragoune 2018-10

감사합니다, 업체에 케이블 점검도 의뢰하겠습니다.
일단 링크는 기가빗으로 나오네요

박문형 2018-10

NETGEAR  GS724Tv4 스위치 랑 3M CAT 5E 혹은 6 정도의 케이블은 써주세요,...

dragoune 2018-10

감사합니다.
월요일에 업체 영업 담당에게 문의넣었는데
문의 폼으로 연락하라더니 아직까지 연락이 없네요.

ZSNET5 2018-10

스위치의 문제로 지연이 생길수도 있고, 누락이 생길 수도 있습니다.
그런데, 5ms도 아니고 5sec는 스위치문제로 생긴 지연이라고 보기에는 너무 과도합니다.
지금 캡쳐를 서버에서 하셨으니 보내고 받은 시점 역시 서버의 시간이고, 그렇다면 저 지연은 스위치가 아니라 서버에서 발생한거라고 보는게 타당한 것으로 사료됩니다.

dragoune 2018-10

답변 감사합니다.
서버 message log나 어플리케이션(asterisk)등 에서는 해당 시간대에 특별히 에러나 워닝 같은게 안보여서 원인을 찾는데 시간이 걸리고 있습니다.
따로 원인을 확인할 방법이 있을런지요?

박문형 2018-10

하위서버가 무엇을 하는 서버인지는 모르지만 시스템 문제가 있을수 있을 듯합니다.

(하드 배드 등으로 데이터가 재대로 못날라가고 지연되는 경우)

어느 서버에서 데이터 오류나 지연이 생기는지부터 확인하세요.. (여러 서버인지 그 서버 하나인지)

dragoune 2018-10

위 패킷은 한대의 서버에서 뜬 in / out 패킷입니다.
하위서버는 pbx입니다만 하위서버에 udp로 보내는 저래서 하위서버와는 무관하게 발생하는게 아닐까 생각하고 있습니다.

HDD 오류라면 뭘로 검사하는게 좋을지요?
부끄럽게도 아직도 리눅스(centos6 입니다)를 잘 모릅니다.
fsck를 쓰게되면 데이터가 다 날아간다고 절대 쓰지말라고 전임자에게 배웠는데 제 자신이 무지해서 무섭네요...

Choryu 2018-10

fsck 쓴다고 데이터가 날아가나요? 처음 듣는 이야기라...

dragoune 2018-10

그래서 부끄럽게도 아직까지 써본적이 없습니다.
처음 리눅스 배울 때 꽤나 소리를 들어서요... ㅎ

박문형 2018-10

서비스중인 리눅스서버의 하드 체크는 하기 어려운 일입니다..

(채크하다 서비스 끊어지면 골치)

하드에서 S.M.A.R.T 채크라는 것이 있는데 리눅스 명령어 중에 이것을 채크할 수 있다면 이 내용으로 하드의 건강상태를 짐작할 수 있습니다..

저도 리눅스는 거의 모르기에....

dragoune 2018-10

윈도우 때는 유틸로 간단히 사용 가능했는데 어찌해야. 할지. 정말 모르겠네요. VM 이면 좋을텐데 이럴땐 물리 서버가 불편하군요.
찾아보겠습니다 ㅎㅎ

깡통이 2018-10

리눅스에서 디스크의 물리적인 오류는 smartctl과 badblocks로 체크하세요.
fsck는 보통 논리적인 오류(파일시스템이나 볼륨의 메타데이터 정보 불일치 등)을 검사할 때 씁니다.

SMART 검사는 smartctl -t long /dev/sdX 같은 형태로 검사하시면 되고요,
이건 하드디스크 펌웨어에서 검사를 하는 것이기 때문에, 시스템이 크게 느려지거나 하는 문제는 없습니다.
그리고 정말 디스크 자체의 문제를 파악할 수 있습니다.

badblocks 는 OS 위에서 디스크를 읽으면서 테스트하는 것이기 때문에 다른 프로세스의 IO에 영향이 있을 수 있습니다.
디스크는 문제가 없지만, 케이블이 문제가 있다거나, SATA컨트롤러가 문제가 있다거나 하는 경우에는
SMART오류는 없는데, 실제 읽기 테스트를 할 때 문제를 발견하게 됩니다.

그리고 데이터를 읽을 때 오류가 발생해야만 문제라고 보는 것이 아니고,
오류가 없다고 하더라도 전송속도가 너무 느리거나, io wait가 높게 나오는 것도 문제가 있다고 봐야합니다.

그리고 fsck로 검사를 하다가 데이터를 날린다는 이야기는,
검사를 하는 것 자체는 문제가 없지만, fsck가 오류를 발견했을 때 수정을 시도하면서 문제가 발생하는 경우가 있습니다.
그게 OS 파티션이고, 마운트되어서 현재 사용중인 파티션이면 오류를 수정하면서 운나쁘게도 시스템이 다운될수도 있는 것이지요.

그리고 제 생각에도 윗분들 말씀처럼 스위치보다는 서버 문제일 가능성을 고려해보시는 것이 좋겠네요.
IO wait가 심하게 높은 경우에는 OS 커널 쪽에서 제때제때 IO 명령을 못 받아줄 수가 있는데요,
사용중인 디스크에 문제가 있거나 컨트롤러에 문제가 발생하면 그런 경우가 있을 수 있습니다.
일시적으로 시스템이 행이 걸렸다가 풀렸다가 하는거죠.
서버에서 SSD를 사용하는데 용량을 거의 풀로 사용하면서 프리징이 걸렸다 풀렸다 하면서 네트웍도 끊어졌다 붙었다 하는 그런 경우도 있었구요.

o홍준기o 2018-10

아닐것 같지만 혹시 IDC에 대역폭 제한은 확인해보셨나요?

그리고 모든 경로를 다 확인해보셨는지요?
올려주신 그림에 reverse 방향의 delta는 올려주지 않아서요.

- 상위서버 -> 운영서버: 상위서버와 운영서버 양쪽에서 패킷 캡쳐해서 비교. 보통은 불가능해서 운영서버에서만 확인하죠.
- 상위서버 <- 운영서버: 상동

- 운영서버 -> 하위서버: 운영서버와 하위서버 양쪽에서 패킷 캡쳐해서 비교. (올리신게 하위서버에서 확인한 패킷을 올리신 것 같은데 맞나요?)
- 운영서버 <- 하위서버: 상동


제가 겪은 경우인데요, 고객사에서 제공한 IDC상면에 서버를 넣었는데 네트웍 대역폭이 부족해서 비슷한 상황이 발생한 적이 있습니다.
IDC의 서버들이 shared 네트웍을 사용하는데 장애발생 당시 고객사에서 배치로 파일전송을 하면서 (그것도 한낮에!!!) 대역폭을 몽땅 사용하고 있어서......
그냥 하루만 그랬으면 넘어갔을텐데 그분들이 뭘 잘못 만들었는지 일주일정도 계속 낮에 배치를 수동으로 돌리는 바람에 ㅋㅋㅋ
IDC랑 우리랑 계약한것도 아니니 대역폭 꽉 차서 장애나는건 우리는 모르고 고객사 담당자가 바뀌었는데 연락처 갱신을 안해서 고객사에서도 모르고 있었고...

고객사 사람이랑 같이 IDC들어가서 확인해보고 알았죠.