간의 데이타교환은 커널버퍼 주소공간과 응용버퍼 주소공간 사이의 메모리복사에 의해 이루어 집니다.
따라서 질문을 바꾸면
소켓 여럿생성 = 응용버퍼를 여러개 생성.
이므로 이케 동작시키면 빨라지나 ..
하는게 됩니다.
소켓 갯수나 응용의 유형에 무관하게 커널은 넷트웍장치에서 커널내부로 진입할 때(드라이버에 의해)와 응용버퍼에서 커널 내부로 진입할 때(커널 자체 루틴에 의해) 독립적으로 skb 를 할당합니다.
독립적이란 말은
서로 다른 fd 로부터의 커널 진입때도 당연히 각 진입마다 다른 주소공간의 skb 가 생기고
하나의 fd 로부터의 경우라도 각 세그먼트 단위의 전송끝까지 여러번의 쓰기때마다 추가로 skb 가 생긴다는 말이며 이 모든 skb 갯수와 크기는 각각 별개로 장치 버퍼로 복사가 완료되었을 때 없어집니다.
즉 fd 가 한개든 여럿이든,시스템에 수많은 다른 넷트웍 응용이 생성한 fd 가 있든 프로세서 우선순위가 같다면 커널 입장에서는 같은 수준으로 skb 를 할당해 줍니다.
이 말은
사용자영역의 메모리 ◀▶ 커널영역의 메모리
로의 복사 우선순위나 거리개념,친구개념이 없다는 말이며 그 말은
같은 목적으로 fd 를 여러개 생성해도 메모리 복사는 한번에 하나만 일어나므로 skb 가 정체되는 경우나 다른 시스템적 요인을 고려하지 않을 때,플밍 로직이나 구현수준이 비슷할 때는 다수의 fd 가 skb 생성속도나 처리속도에 악영향을 줬으면 줬지 긍정적이지는 않을겁니다.
끝으로
KLDP 에서만큼은
현직에 계신 분이나 경험자분이나, 고수분이나 전문가분이나...이런분의 조언을 구한다는 식의 조건이 달린 질문이 적었으면 좋겠다는 생각을 합니다.
저같은 경우 답변자격미달이거든요 ㅎㅎㅎ
'기타 시스템적 요인을 고려하지 않을 때'
를 쉽게 이미지로 그려보면 아래 부분을 고려하지 않고 말했을 때 입니다.
시스템에 아파치 관련 fd 1개,내가 플밍한 fd 1개 딱 2개가 있다고 보고
좀 황당하지만 응용수준에서 아파치와 내 프로그램의 처리수준과 프로세서 우선순위도 같다면
커널의 skb 생성과 처리 속도효율은 0.5 : 0.5 가 될 것입니다.
여기서 내가 8개를 더 만들면 0.1 : 0.9 가 되겠죠.
따라서 커널에 skb 가 100개 200개 정체되어 있다치면 그 중 내것이 훨씬 많고 체감상 아파치가 느려지는 정도가 내 프로그램이 느려지는 정도보다 심각할 것입니다.
이 때
"봐라 효과 있쟎아"
할 수도 있다는 것입니다.
skb 가 정체되지 않을 때는 커널이 산뜻하고 넷트웍관련 문제가 없으며 물리적인 메모리 복사 속도가 충분히 빠르다는 말이므로 fd 를 여럿 만들어 사용자 버퍼주소공간을 조각화시키고 커널 연산을 증가시키는 것은 오히려 악영향이라는 것입니다.
반면 바쁜 시스템에서
커널 내부에 내 skb 비율을 높여서 전송속도를 높이고자 하는 시도는 언뜻 매력적으로 들리지만
프로세서 우선순위를 다르게 하거나 백로그를 다르게 하거나 커널 넷트웍-전송 루틴을 손보는 방법보다 더 무식한 시도입니다.
skb 가 정체된다는 것은 물리적이든 논리적이든 I/O 에 문제가 있어서 커널이 메모리를 홀딩하고 있는 시간이 길다는 소린데 이런 시스템에서 skb 숫자를 늘이려 한다거나 backlog 값을 늘인다거나...하는건 근본적인 시도가 아닙니다. 대표적으로 전송 backlog 를 1024로 하면 좋다 카더라~~
하는게 있죠.
커널 변수조작도 쓰잘데 없는거고,더구나 응용의 fd 를 늘이겠다...역시 삽질입니다.
한가지 더 예외로 치면 물리적으로 메모리 컨트롤러,CPU 가 여럿일 때는 이런 시도가 유효할 수도 있습니다.
특정 파일의 offset 으로 요청할 수 있는 이어받기 프로토콜이 있습니다.
따라서 필요한 받큼만 받고 끊어버리는 커넥션을 여러 개 만들면 같은 파일을 병렬로 받을 수 있습니다.
접속지별 커넥션 갯수 설정이 느슨한 대신 커넥션 별 대역폭 설정이 강력하게 되어 있는 서버에 접속할 경우 이득이 있습니다.
http, ftp 모두 프로토콜을 가지고 있지만, 서버가 이를 반드시 구현할 의무는 없습니다.
네.. 당연하죠.. leechftp 라고 찾아보세요.
그 개념이 구현되어 있음
첮아봤는데 자료가 별로 없네요ㅜ
leech ftp에서 멀티쓰레드를 쓴다는건 알겠는데 어떤식으로 사용하는것인가요??
파일이 100mb라고 한다면 열개의 소켓연결을 하고, 각각의 소켓연결을 통해 10mb씩 보내서 총 100mb를 전송하는 개념이 맞나요??
간의 데이타교환은 커널버퍼 주소공간과 응용버퍼
간의 데이타교환은 커널버퍼 주소공간과 응용버퍼 주소공간 사이의 메모리복사에 의해 이루어 집니다.
따라서 질문을 바꾸면
소켓 여럿생성 = 응용버퍼를 여러개 생성.
이므로 이케 동작시키면 빨라지나 ..
하는게 됩니다.
소켓 갯수나 응용의 유형에 무관하게 커널은 넷트웍장치에서 커널내부로 진입할 때(드라이버에 의해)와 응용버퍼에서 커널 내부로 진입할 때(커널 자체 루틴에 의해) 독립적으로 skb 를 할당합니다.
독립적이란 말은
서로 다른 fd 로부터의 커널 진입때도 당연히 각 진입마다 다른 주소공간의 skb 가 생기고
하나의 fd 로부터의 경우라도 각 세그먼트 단위의 전송끝까지 여러번의 쓰기때마다 추가로 skb 가 생긴다는 말이며 이 모든 skb 갯수와 크기는 각각 별개로 장치 버퍼로 복사가 완료되었을 때 없어집니다.
즉 fd 가 한개든 여럿이든,시스템에 수많은 다른 넷트웍 응용이 생성한 fd 가 있든 프로세서 우선순위가 같다면 커널 입장에서는 같은 수준으로 skb 를 할당해 줍니다.
이 말은
사용자영역의 메모리 ◀▶ 커널영역의 메모리
로의 복사 우선순위나 거리개념,친구개념이 없다는 말이며 그 말은
같은 목적으로 fd 를 여러개 생성해도 메모리 복사는 한번에 하나만 일어나므로 skb 가 정체되는 경우나 다른 시스템적 요인을 고려하지 않을 때,플밍 로직이나 구현수준이 비슷할 때는 다수의 fd 가 skb 생성속도나 처리속도에 악영향을 줬으면 줬지 긍정적이지는 않을겁니다.
끝으로
KLDP 에서만큼은
현직에 계신 분이나 경험자분이나, 고수분이나 전문가분이나...이런분의 조언을 구한다는 식의 조건이 달린 질문이 적었으면 좋겠다는 생각을 합니다.
저같은 경우 답변자격미달이거든요 ㅎㅎㅎ
'기타 시스템적 요인을 고려하지 않을 때' 를 쉽게
'기타 시스템적 요인을 고려하지 않을 때'
를 쉽게 이미지로 그려보면 아래 부분을 고려하지 않고 말했을 때 입니다.
시스템에 아파치 관련 fd 1개,내가 플밍한 fd 1개 딱 2개가 있다고 보고
좀 황당하지만 응용수준에서 아파치와 내 프로그램의 처리수준과 프로세서 우선순위도 같다면
커널의 skb 생성과 처리 속도효율은 0.5 : 0.5 가 될 것입니다.
여기서 내가 8개를 더 만들면 0.1 : 0.9 가 되겠죠.
따라서 커널에 skb 가 100개 200개 정체되어 있다치면 그 중 내것이 훨씬 많고 체감상 아파치가 느려지는 정도가 내 프로그램이 느려지는 정도보다 심각할 것입니다.
이 때
"봐라 효과 있쟎아"
할 수도 있다는 것입니다.
skb 가 정체되지 않을 때는 커널이 산뜻하고 넷트웍관련 문제가 없으며 물리적인 메모리 복사 속도가 충분히 빠르다는 말이므로 fd 를 여럿 만들어 사용자 버퍼주소공간을 조각화시키고 커널 연산을 증가시키는 것은 오히려 악영향이라는 것입니다.
반면 바쁜 시스템에서
커널 내부에 내 skb 비율을 높여서 전송속도를 높이고자 하는 시도는 언뜻 매력적으로 들리지만
프로세서 우선순위를 다르게 하거나 백로그를 다르게 하거나 커널 넷트웍-전송 루틴을 손보는 방법보다 더 무식한 시도입니다.
skb 가 정체된다는 것은 물리적이든 논리적이든 I/O 에 문제가 있어서 커널이 메모리를 홀딩하고 있는 시간이 길다는 소린데 이런 시스템에서 skb 숫자를 늘이려 한다거나 backlog 값을 늘인다거나...하는건 근본적인 시도가 아닙니다. 대표적으로 전송 backlog 를 1024로 하면 좋다 카더라~~
하는게 있죠.
커널 변수조작도 쓰잘데 없는거고,더구나 응용의 fd 를 늘이겠다...역시 삽질입니다.
한가지 더 예외로 치면 물리적으로 메모리 컨트롤러,CPU 가 여럿일 때는 이런 시도가 유효할 수도 있습니다.
헛수고입니다.
왜 그런방식을 시도하시려는건지는 잘 모르겠으나, FTP 프로토콜 자체가 질문하신 분께서
말씀하신 방식의 파일전송을 지원하지 않습니다.
leechftp는 여러개의 파일을 동시에 전송하는 프로그램이지 파일을 분할해서 전송하는
방식은 아닙니다.
특정 파일의 offset 으로 요청할 수 있는
특정 파일의 offset 으로 요청할 수 있는 이어받기 프로토콜이 있습니다.
따라서 필요한 받큼만 받고 끊어버리는 커넥션을 여러 개 만들면 같은 파일을 병렬로 받을 수 있습니다.
접속지별 커넥션 갯수 설정이 느슨한 대신 커넥션 별 대역폭 설정이 강력하게 되어 있는 서버에 접속할 경우 이득이 있습니다.
http, ftp 모두 프로토콜을 가지고 있지만, 서버가 이를 반드시 구현할 의무는 없습니다.
http://en.wikipedia.org/wiki/
http://en.wikipedia.org/wiki/GridFTP
위 페이지 참고하시고... 제대로 구현하면 효과는 꽤 있습니다.
삼성SDS에서 만든것도 있으니 참고로 보시길: http://rapidant.sourceforge.net/
--
익스펙토 페트로눔
댓글 달기