웹서버를 다운 시키는 것이 이렇게 어려울 줄이야

RisaPapa의 이미지

관련글: http://bbs.kldp.org/viewtopic.php?t=40989

어제 저녁부터 아파치 웹서버를 다운 시켜보려고 별 수단을 다 써도 다운이 되지않는군요. 어떤 특효약이라도 있는지 알고 싶습니다. 이미 알려진 방법은 대부분 써보았습니다만 그래도 끄떡없다는 것이 신기하기만 합니다.

사실 윈도우2000 서버에서 아파치2를 테스트하기 전에 리눅스는 테스트를마쳤는데 3시간 정도에 다운 시킬 수가 있었습니다. 현재 위의 관련글에 쓰여있는 사양이고 같은 서버를 사용해서입니다. 또 듀얼로도 하고 메모리를 1기가로 해서도 테스트를 했는데 역시 비슷한 정도의 시간에 다운을 시킬 수가 있었습니다.

그러면서 웹서버에 대한 생각들이 조금식 바뀌고 운영시스템에 의한 차이는 없다는 생각과 아파치2에 한해서는 오픈소스의 아파치(2)를 사용할 때에는 어쩌면 윈32계열(윈2000)이 더 성능면에서 월등하고 안정적이지 않나 하는 생각을 하게 됩니다.

자바의 경우에는 윈도우 계열로 현재 배포되고 있는 버전의 자바 버츄얼 머신과 톰캣5에서는 리눅스를 한참 앞서가고 있다는 생각을 하기도 합니다. 그 외에 밸런싱까지도 모두 지원을 하니 현재 리눅스의 여러 벤더의 배포버전과 업그레이드등을 고려 할때 기업의 입장으로서는 이러한 사실과 데이터를 가지고 있으면 윈2000이나 2003 서버 계열에서 오픈소스를 사용하려는 움직임이 강해 지지 않을까하는 걱정도 됩니다. 실제로 유럽쪽에서는 이 움직임이 조금씩 나타나고 있다는 느낌이 듭니다.

현재 저는 64비트 리눅스 디스트리뷰션과 애플리케이션 개발로 시프트하고 있는데 올해에 윈XP가 64비트 버전을 내놓을 것이라는 정보등을 듣고 있노라면 현재의 많은 벤더의 리눅스는 오히려 리눅스의 발전을 저해 하지 않을까하는 생각을 해봅니다.

제가 생각하고 있는 디스트리뷰션은 커넬에서 사용하는 LIBC와 애플리 케이션에서 사용하는 LIBC의 완전한 분리 입니다. 그리고 커넬영역에서는 LIBC가 STATIC컴파일로 변화되어야만 한다는 생각입니다. 그렇지 않으면 개발자와 시스템 관리자가 많이 힘이 들것이라는 생각을 하고 있습니다. 다시 말해서 커넬 영역의 컴파일러 버전은 변화 되지않고 버그의 수정만이 가능한 폴리시가 필요하다는 말입니다. 그렇지 않으면 리눅스에서의 디펜던시는 절대로 개선될 수가 없을 것입니다. 다시 말해서 컴파일러 레벨에서 커넬만을 위한 GCC와 애플리케이션만을 지원하는 GCC의 분리입니다. 물론 LIBC도 마찬가지 입니다.

요즘은 정부가 IT쪽으로 이것 저것 쓸데 없는데에 돈을 많이 쓰는 것을 보면 한국의 정부를 위해서 한번 일하고 싶은 생각도 많이 하게 됩니다. 한국의 철학에서 출발한 리눅스라든지 이런 것을 만들어 보고 싶은 나날 들입니다. 그러나 나이가 이제 40이 다 되어 가니 기력이 얼마나 남아 있을 런지...

아무튼 서버를 한번 다운 시켜줄 분은 없는지....,

여러 애플리케이션을 인스톨해야 하는지. 그러면 내일은 phpBB를 PgSQL 데이터 서버를 사용해서 돌려 놓겠습니다. 정말로 서버가 공격을 받아서 다운 되는 모습을 한번 보고 싶습니다. 완전한 다운입니다.

byung82의 이미지

대용량 파일 다운로드를 좀 걸어보시는것을 어떨까요 ?

그런방식도 괜잖을거라 생각이듭니다.

한번 대용량 파일 다운로드로 한번 도전 해보시기 바랍니다.

단 내용을 읽어보니깐 fastCGI쓰시는것 같은데 ^^:

일단 fastCGI에 걸리지 않고 바로 다운로드 하는방식과

fastCGI에서 다운 해주는 방식 2가지를 해보시면 되겠죠 ^:^

한 1G짜리로 막 걸어서 해보시면 될것도 같습니다.

그럼

angpoo의 이미지

가끔 사용자 폭주로 서버가 다운됐다고 자랑하는 싸이트나 뉴스를 보면 정말 가소롭습니다.
심지어 어느 싸이트는 사용자 폭주로 서버 다운됐다는 기사를 내고
실제 홈피에는 http response code는 200 OK로 나오면서
마치 동접자가 많아서 출력되는 에러메시지 페이지 인양 꾸며놓은 곳도 봤습니다.

RisaPapa의 이미지

byung82 wrote:
대용량 파일 다운로드를 좀 걸어보시는것을 어떨까요 ?

그런방식도 괜잖을거라 생각이듭니다.

한번 대용량 파일 다운로드로 한번 도전 해보시기 바랍니다.

단 내용을 읽어보니깐 fastCGI쓰시는것 같은데 ^^:

일단 fastCGI에 걸리지 않고 바로 다운로드 하는방식과

fastCGI에서 다운 해주는 방식 2가지를 해보시면 되겠죠 ^:^

한 1G짜리로 막 걸어서 해보시면 될것도 같습니다.

그럼

대용량 파일은 대역폭이 있으니 조금 꺼려집니다.
전에도 그랬지만 서버는 다운되지 않고 대역폭 때문에 클라이언트에
전송되는 스피드수치만 낮아질 뿐입니다.

offree의 이미지

테스트를 위해 테스트 의향이 있는 분을 모으고, 일정시간을 정해서
동시에 테스트를 하는 것이 좋지 않을 까 합니다.

말씀대로 대용량 파일은 대역폭때문에 막힐 것 같구요.

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

pyrasis의 이미지

페이지 새로고침 공격은 어떤가요?

공격 방법은 별 다른것 없고 어떤 간단한 프로그램을 이용해서
웹브라우저로 특정 페이지 로딩을 무한 반복하는것입니다.

일전에 DcInside 라는 디지털 카메라 사이트의 사용자들이 개발한

방법 2003이라는 프로그램이 새로고침 공격 프로그램에 해당합니다.

zflute의 이미지

pyrasis wrote:
페이지 새로고침 공격은 어떤가요?

공격 방법은 별 다른것 없고 어떤 간단한 프로그램을 이용해서
웹브라우저로 특정 페이지 로딩을 무한 반복하는것입니다.

일전에 DcInside 라는 디지털 카메라 사이트의 사용자들이 개발한

방법 2003이라는 프로그램이 새로고침 공격 프로그램에 해당합니다.

ab 만으로도 충분히 같은 효과를 낼 수 있지 않나요?
브라우저 기반의 스크립트를 이용한 새로고침 툴 보다는 쉘에서 동작하는 ab가 더 효과적일 것 같습니다.

penrose의 이미지

이쪽 분야에 대해 제가 잘은 모르지만, 대역폭이 문제라는 것 자체가 목적을 달성하는 데 있어서 큰 제약조건이 아닐까 하는 생각이 드네요.

What a wonderful world!

vacancy의 이미지

lbic가 아니라 libc 이야기이신 것 같은데요.
kernel build 시 libc는 당연히 static 하게 link 됩니다.
kernel이 올라오는 동안 dynamic 하게 link 하는 것은 무리가 있죠.

linux의 경우 kernel은 어차피 현재 환경의 libc를 지니고
새로 build하는 것이 보통이라서,
kernel과 libc 간의 문제는 없을 것 같은데요.

libc dependency의 문제는 그쪽이 아니라,
libc가 upgrade 됐을 때, 여기에 dynamic link 를 하도록 되어있던
기존 binary 들이 문제가 되는 것 같습니다.
( kernel은 static link 로 build 되므로 이러한 문제가 없을 것 같은데요. )
새로 빌드가 수행되어야 하니까요.

이러한 문제도 배포판들이 나름대로 극복하는 것 같던데요.
사실 다른 배포판들은 잘 모르겠고,
debian 배포판의 경우는 libc upgrade 후에
( 과정은 잘 모르겠지만 ) 어떻게 잘 처리해서 기존 binary 들도 돌리더군요.
gentoo 등도 별 문제가 없지 않을까 생각합니다.

RisaPapa의 이미지

vacancy wrote:
lbic가 아니라 libc 이야기이신 것 같은데요.
kernel build 시 libc는 당연히 static 하게 link 됩니다.
kernel이 올라오는 동안 dynamic 하게 link 하는 것은 무리가 있죠.

linux의 경우 kernel은 어차피 현재 환경의 libc를 지니고
새로 build하는 것이 보통이라서,
kernel과 libc 간의 문제는 없을 것 같은데요.

libc dependency의 문제는 그쪽이 아니라,
libc가 upgrade 됐을 때, 여기에 dynamic link 를 하도록 되어있던
기존 binary 들이 문제가 되는 것 같습니다.
( kernel은 static link 로 build 되므로 이러한 문제가 없을 것 같은데요. )
새로 빌드가 수행되어야 하니까요.

이러한 문제도 배포판들이 나름대로 극복하는 것 같던데요.
사실 다른 배포판들은 잘 모르겠고,
debian 배포판의 경우는 libc upgrade 후에
( 과정은 잘 모르겠지만 ) 어떻게 잘 처리해서 기존 binary 들도 돌리더군요.
gentoo 등도 별 문제가 없지 않을까 생각합니다.

전에 OS영역 서버영역 언어영역 데스크톱영역을 4개로 분리하여 배포버전을
만들려다 너무나 노가다 작업이라서 포기를 한적이 있는데 커넬에서 로드되는
라이브러리를 체크하니 libc가 링크에 걸려 있어서 동적으로 컴파일이 되는
부분이 있다는 생각을 했습니다. 그리고 커넬의 LIBC버전과 애플리케이션의
LIBC버전이 서로 다른 것을 사용하면 부트조차 되지 않는 경우도 허다 하고
해서 완전한 분리는 되지 않았다는 생각이 듭니다. 레드햇8/9 미라클 리눅스로
작업을 했었는데 이 때에 많이 고생을 한 적이 있어서 지금은 레드햇계열을
아주 싫어 하게 되었습니다. 이 이후로 회사내에서 사용하는 OS에서 레드햇
계열 몰아내기에 전력해 와서 이제는 SUSE로 교체되어 가는 중입니다.

아마 내년 상반기 부터 64비트 리눅스 디스트리뷰션 제작을 한번 시작해
보려고 합니다. 그 때가 되면 GCC나 라이브러리 관계도 어느정도 안정성이
보장될 것이라고 생각이 되기때문입니다. 그 외에도 RPM이나 포츠등과 같은
업데이트 관련의 많은 관련 사항이 있는데 생략하겠습니다. 저는 펄을 주로
해왔기 아마 펄로 다시 제작하게 되리라고 생각됩니다.

wkpark의 이미지

vacancy wrote:
lbic가 아니라 libc 이야기이신 것 같은데요.
kernel build 시 libc는 당연히 static 하게 link 됩니다.
kernel이 올라오는 동안 dynamic 하게 link 하는 것은 무리가 있죠.

리눅스 커널을 만들 때 glibc를 링크한다는 것은 금시 초문입니다.
몇몇 gzip등등의 관련 함수는 아예 소스에 같이 들어있을 뿐..

RisaPapa wrote:

제가 생각하고 있는 디스트리뷰션은 커넬에서 사용하는 LBIC와 애플리 케이션에서 사용하는 LBIC의 완전한 분리 입니다. 그리고 커넬영역에서는 LBIC가 STATIC컴파일로 변화되어야만 한다는 생각입니다. 그렇지 않으면 개발자와 시스템 관리자가 많이 힘이 들것이라는 생각을 하고 있습니다. 다시 말해서 커넬 영역의 컴파일러 버전은 변화 되지않고 버그의 수정만이 가능한 폴리시가 필요하다는 말입니다. 그렇지 않으면 리눅스에서의 디펜던시는 절대로 개선될 수가 없을 것입니다. 다시 말해서 컴파일러 레벨에서 커넬만을 위한 GCC와 애플리케이션만을 지원하는 GCC의 분리입니다. 물론 LBIC도 마찬가지 입니다.

아래 명령을 단 한번이라도 내려보시거나, Makefile을 보고 확인하셨다라면... ^^;;
$ ldd vmlinux
        not a dynamic executable

그리고, 정확히 어떤 디펜던시를 말씀하시는 것인지요?

패키지간의 의존성을 말씀하시는 것이라면, 바이너리 패키지간의 의존성은 이 배포판에서 저 배포판으로 넘어갈 때를 절대로 책임지지 못합니다. 이런 것은 중앙에서 통제된다면 쉽게 가능하겠고 그러한 좋은 예로는 FreeBSD가 있겠고, 데비안과 같은 정교한 배포판을 쓰세요. (그밖에 소스기반의 배포판은 의존성 문제를 0에 가깝게 확실히 줄여줍니다.)

그리고 당연히도, 데비안과 같은 좋은 배포판이라 해도 버전이 각기 다른 바이너리 패키지를 같이 쓴거나, 디펜던시 운운하는 것은 넌센스겠죠.

패키지의 디펜던시가 아니라, 최근에 리눅스 커널의 thread관련된 기능과 glibc간의 관계 등등을 말씀하시는 것이라면, 이러한 최신의 기능이 처음 탄생하게 될 때 개발자들이 겪게 되는 여러 문제점이라고 밖에 말할 수 없습니다.
(http://kerneltrap.org/node.php?id=429
여기의 glibc 메인테이너 Ulrich Drepper씨는 RedHat으로 옮긴지 오래되었죠.)

RisaPapa wrote:

현재 저는 64비트 리눅스 디스트리뷰션과 애플리케이션 개발로 시프트하고 있는데 올해에 윈XP가 64비트 버전을 내놓을 것이라는 정보등을 듣고 있노라면 현재의 많은 벤더의 리눅스는 오히려 리눅스의 발전을 저해 하지 않을까하는 생각을 해봅니다.

비슷한 글을 어디선가 본 것 같기도 한데, 어떠한 발전을 어떠한 방식으로 저해할 것인가에 대해 좀 더 자세히 기술해 주시면 감사하겠습니다. ^^

온갖 참된 삶은 만남이다 --Martin Buber

offree의 이미지

RisaPapa wrote:

제가 생각하고 있는 디스트리뷰션은 커넬에서 사용하는 LIBC와 애플리 케이션에서 사용하는 LIBC의 완전한 분리 입니다. 그리고 커넬영역에서는 LIBC가 STATIC컴파일로 변화되어야만 한다는 생각입니다. 그렇지 않으면 개발자와 시스템 관리자가 많이 힘이 들것이라는 생각을 하고 있습니다. 다시 말해서 커넬 영역의 컴파일러 버전은 변화 되지않고 버그의 수정만이 가능한 폴리시가 필요하다는 말입니다. 그렇지 않으면 리눅스에서의 디펜던시는 절대로 개선될 수가 없을 것입니다. 다시 말해서 컴파일러 레벨에서 커넬만을 위한 GCC와 애플리케이션만을 지원하는 GCC의 분리입니다. 물론 LIBC도 마찬가지 입니다.

위 말씀은 .. 애플리케이션 과 커널의 libc 가 연결이 되어 있기 때문에..

애플리케이션 의 이상이 커널에 영향을 미친다는 말씀이신지요?

그래서 위 리눅스의 다운현상이 그런연유로 발생했다는 것인지요?

자세한 사항은 잘 모르지만, 그렇다고 한다면, 커널자체가 그에 대한 방어책(?)이 없다는 말이되나요.

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

RisaPapa의 이미지

Quote:

아래 명령을 단 한번이라도 내려보시거나, Makefile을 보고 확인하셨다라면... ^^;;
$ ldd vmlinux
        not a dynamic executable


네 지금 확인을 해보았습니다. 제가 잘못 알고 있었군요. KERNEL32.DLL의 디펜던시는 NT.DLL인것을 보면 MSVCRT.DLL과는 관계가 없으니까요. 감사합니다.

Quote:

그리고, 정확히 어떤 디펜던시를 말씀하시는 것인지요?

패키지간의 의존성을 말씀하시는 것이라면, 바이너리 패키지간의 의존성은 이 배포판에서 저 배포판으로 넘어갈 때를 절대로 책임지지 못합니다. 이런 것은 중앙에서 통제된다면 쉽게 가능하겠고 그러한 좋은 예로는 FreeBSD가 있겠고, 데비안과 같은 정교한 배포판을 쓰세요. (그밖에 소스기반의 배포판은 의존성 문제를 0에 가깝게 확실히 줄여줍니다.)

그리고 당연히도, 데비안과 같은 좋은 배포판이라 해도 버전이 각기 다른 바이너리 패키지를 같이 쓴거나, 디펜던시 운운하는 것은 넌센스겠죠.

제가 생각하고 있는 디펜던시관련은 윈32와 같이 다른 것들도 있지만 MSVCRT.DLL 파일만 있으면 왠만한 프로그램은 거의 해결이 됩니다. 심지어 윈도우95에서 돌아가도록 프로그램한 것들도 윈2000에서도 작동이 되고 윈도우3.2인가 하는 16비트 프로그램도 작동이 되는 경우가 있습니다. 저는 지금도 가끔 비쥬얼 C++ 1.0 버전도 윈도우 2000에서 사용하고 있습니다. 리눅스에서도 기본 라이브러리 관련은 이 정도로 철저히 관리가 되어야만 하지 않을까하는 생각을 기본으로하는 디펜던시입니다.

LIBC의 버전에 따라서 컴파일 하는데에도 많은 문제가 발생 하기도 합니다. 제가 작년에 서버관련 프로그램을 스크립으로 단 한방에 펄이라든지 파이선등등 언어에서 라이브러리 메일 디비 웹 LDAP등을 모두 빌드하는 소스를 작성한 적이 있었는데 가장 문제가 되었던 것이 GCC와 LIBC이었습니다. 그래서 GCC와 LIBC를 업그레이드한 후에 작성을 하는 방법과 공존하는 방법으로 했는데 너무나 고생을 해서 잠시 리눅스에서 손을 뗀 적이 있습니다. 소스로 빌드를 한다고 해도 그많은 배포판을 지원 할수가 없어 일단은 레드햇계열만 가능하게 했습니다.

서로 다른 운영시스템에 대한 가치관과 철학이 있을 것이 라고 생각을 하지만 일반 리눅스의 배포버전이라면 적어도 바이너리 레벨에서는 문제가 없어야 할 것이라고 생각을 하는 입장입니다. 같은 커넬을 기반으로 하기 때문에 가장 기본적인 라이브러리인 LIBC에서만 문제가 없다면 아마 리눅스는 지금보다 훨씬 더 발전되었고 수세나 데비안 레드햇등의 서로 다른 배포판이라도 버전이 조금 다르더라도 바이너리의 호환성을 어느정도 유지되고 있지 않을까하는 생각입니다.

Quote:

비슷한 글을 어디선가 본 것 같기도 한데, 어떠한 발전을 어떠한 방식으로 저해할 것인가에 대해 좀 더 자세히 기술해 주시면 감사하겠습니다. ^^

시대의 흐름으로 그냥 그러한 생각이 드는 것뿐입니다. 선택을 하는 데에 리눅스에 지식이 있는 사람으로서는 여러 벤더에서 많은 팩키지가 나와 선택을 하는 것도 즐거울 수가 있지만 개발자들이 생각하는 것과는 달리 일반사람이나 회사의 관리자에게는 고민거리를 더 안겨주는 것에 지나지 않는다고 생각됩니다. 회사에서 어려운 개념들을 많이 다루다 보니 많은 사람들이 사용하는 휴대전화등의 애플리케이션을 설명을 하는데에 논문을 발표하는 분위기가 계속되어 제가 한번 화를 내적이 있습니다. 이유는 모든 사람들이 그 전문적인 것에 대해서 당신들처럼 관심을 가지는 것도 아닌데 무슨 학회에서 벼슬한 것처럼 논문발표를 하는 식으로 영업하고 전시회에서 일반 사람에게 설명을 하는지에 대해서 제가 많은 거부감이 있었기 때문입니다.

그리고 제가 덧붙인 말은 모든 사람들을 바보라고 생각하고 그 사람들이 알아 들을 수 있는 레벨로 설명을 하고 간단화 시키지 않으면 절대로 회사로서 살아 남을 수가 업다는 것이 었습니다.

이처럼 운영시스템에 대해서도 어느정도 위와 같은 내용이 작용하는 것이 아닌가 하는 생각이 들고 특히 리눅스가 성공를 하려면 데스크톱에서 성공을 해야하는데 타겟은 일반 개발자가 아니라 시스템에 대히서 아무것도 모르는 일반인이라는 것이기 때문입니다.

vacancy의 이미지

박원규 wrote:
vacancy wrote:
lbic가 아니라 libc 이야기이신 것 같은데요.
kernel build 시 libc는 당연히 static 하게 link 됩니다.
kernel이 올라오는 동안 dynamic 하게 link 하는 것은 무리가 있죠.

리눅스 커널을 만들 때 glibc를 링크한다는 것은 금시 초문입니다.
몇몇 gzip등등의 관련 함수는 아예 소스에 같이 들어있을 뿐..

제가 정확히 몰랐나 봅니다.
memcpy 같은 거의 OS independent한 명령들은
가져다 사용하는 case가 많이 있어서
Linux에서도 그렇겠거니 했네요.
glibc 없이 Linux 빌드하는 경우를 사실 접한 적이 없다보니. -_-;

정확하지 않은 글을 올려 죄송합니다.

pynoos의 이미지

RisaPapa wrote:

서로 다른 운영시스템에 대한 가치관과 철학이 있을 것이 라고 생각을 하지만 일반 리눅스의 배포버전이라면 적어도 바이너리 레벨에서는 문제가 없어야 할 것이라고 생각을 하는 입장입니다. 같은 커넬을 기반으로 하기 때문에 가장 기본적인 라이브러리인 LIBC에서만 문제가 없다면 아마 리눅스는 지금보다 훨씬 더 발전되었고 수세나 데비안 레드햇등의 서로 다른 배포판이라도 버전이 조금 다르더라도 바이너리의 호환성을 어느정도 유지되고 있지 않을까하는 생각입니다.

저도 여러 Linux를 고려해야하는 제품을 만드는 개발자로서, 각 배포판마다 서로 다른 라이브러리 의존성때문에 심각한 고민을 합니다.
배포판은 완전히 다른 운영체제다라고 생각하지 않으면 안되죠.

제 생각에 리눅스가 라이브러리들의 soname과 exported symbol list 들을 관리할 수 있다면(혹시 권고 표준이라도 있는지는 모르겠습니다만) 좀더 강력해지지 않을까 합니다.

그런 걱정의 예가 ./configure --help에서 나타나는 수많은 enable, with 선택사항들을 보면, 배포판이 어떤걸 선택해주느냐에 따라 같은 soname을 가진 라이브러리라도 다른 곳에 가져가면 없는 심볼때문에 고생하게 됩니다.
(보통 배포판에서는 모든 것을 enable 시켜서 배포하나요?)

처음 주제와는 조금 벗어난 글을 썼군요.. :)

RisaPapa님의 의견에 동의하는 생각이 들어서 잠시 끄적여 봤습니다.

creativeidler의 이미지

Quote:
가끔 사용자 폭주로 서버가 다운됐다고 자랑하는 싸이트나 뉴스를 보면 정말 가소롭습니다.
심지어 어느 싸이트는 사용자 폭주로 서버 다운됐다는 기사를 내고
실제 홈피에는 http response code는 200 OK로 나오면서
마치 동접자가 많아서 출력되는 에러메시지 페이지 인양 꾸며놓은 곳도 봤습니다.

사용자 폭주한다는 에러 페이지가 나오면서 200 OK가 나오는 건 사용자 폭주로 인해 웹서버가 딸린다는 게 아니고 데이터베이스 커넥션 풀이 모자라는 경우입니다. 이 경우 웹서버는 정상 처리가 가능하기 때문에 지정된 에러 페이지를 보내주는데 에러 코드를 200 OK로 일부러 바꿔서 보냅니다. 안 그러면 브라우저에 따라 익스플로러 자체 에러페이지를 뿌려주기 때문이죠. 실제로 사용자 폭주 자체 때문에 웹서버나 톰캣 서버가 죽는 일은 상당히 드물죠. 대부분 데이터베이스 문제입니다.

다즐링의 이미지

어떤방법을 쓰셔셔 아파치(onLinux) 를 다운 시키셧나요?

기존에 올리신 ab -n 10000000 -c 5 정도의 방법인지요?

RisaPapa wrote:
관련글: http://bbs.kldp.org/viewtopic.php?t=40989

어제 저녁부터 아파치 웹서버를 다운 시켜보려고 별 수단을 다 써도 다운이 되지않는군요. 어떤 특효약이라도 있는지 알고 싶습니다. 이미 알려진 방법은 대부분 써보았습니다만 그래도 끄떡없다는 것이 신기하기만 합니다.

사실 윈도우2000 서버에서 아파치2를 테스트하기 전에 리눅스는 테스트를마쳤는데 3시간 정도에 다운 시킬 수가 있었습니다. 현재 위의 관련글에 쓰여있는 사양이고 같은 서버를 사용해서입니다. 또 듀얼로도 하고 메모리를 1기가로 해서도 테스트를 했는데 역시 비슷한 정도의 시간에 다운을 시킬 수가 있었습니다.

그러면서 웹서버에 대한 생각들이 조금식 바뀌고 운영시스템에 의한 차이는 없다는 생각과 아파치2에 한해서는 오픈소스의 아파치(2)를 사용할 때에는 어쩌면 윈32계열(윈2000)이 더 성능면에서 월등하고 안정적이지 않나 하는 생각을 하게 됩니다.

------------------------------------------------------------------------------------------------
Life is in 다즐링

blacknblue의 이미지

리눅스에서는 3시간만에 다운되었다고 하셨는데 그 원인이 무엇이었나요?
메모리 관리등에 있어서 리눅스가 훨씬 못하다는 말씀인지...

권순선의 이미지

pynoos wrote:
RisaPapa wrote:

서로 다른 운영시스템에 대한 가치관과 철학이 있을 것이 라고 생각을 하지만 일반 리눅스의 배포버전이라면 적어도 바이너리 레벨에서는 문제가 없어야 할 것이라고 생각을 하는 입장입니다. 같은 커넬을 기반으로 하기 때문에 가장 기본적인 라이브러리인 LIBC에서만 문제가 없다면 아마 리눅스는 지금보다 훨씬 더 발전되었고 수세나 데비안 레드햇등의 서로 다른 배포판이라도 버전이 조금 다르더라도 바이너리의 호환성을 어느정도 유지되고 있지 않을까하는 생각입니다.

저도 여러 Linux를 고려해야하는 제품을 만드는 개발자로서, 각 배포판마다 서로 다른 라이브러리 의존성때문에 심각한 고민을 합니다.
배포판은 완전히 다른 운영체제다라고 생각하지 않으면 안되죠.

제 생각에 리눅스가 라이브러리들의 soname과 exported symbol list 들을 관리할 수 있다면(혹시 권고 표준이라도 있는지는 모르겠습니다만) 좀더 강력해지지 않을까 합니다.

그런 걱정의 예가 ./configure --help에서 나타나는 수많은 enable, with 선택사항들을 보면, 배포판이 어떤걸 선택해주느냐에 따라 같은 soname을 가진 라이브러리라도 다른 곳에 가져가면 없는 심볼때문에 고생하게 됩니다.
(보통 배포판에서는 모든 것을 enable 시켜서 배포하나요?)

처음 주제와는 조금 벗어난 글을 썼군요.. :)

RisaPapa님의 의견에 동의하는 생각이 들어서 잠시 끄적여 봤습니다.


LSB(Linux Standard Base)가 그런 문제 때문에 많은 노력을 하고 있죠. 모든 배포판이 LSB 호환을 유지한다면 개발자는 본인의 application이 LSB 호환인지를 확인하는 것으로 모든 배포판에서 잘 동작한다고 일단 봐도 되는 것이죠. LSB 홈페이지에 아마 LSB 호환성 검증 키트와 개발 도구들이 있을 것입니다.

문제는, 배포판 개발 회사(개인)들과 애플리케이션 개발 회사(개인)들이 이를 얼마나 중요하게 생각하고 잘 지키느냐인데 여러가지 현실적인 문제들 때문에 100% 완벽한 방법이 되지는 못하고 있습니다. 예를 들자면 이런 겁니다.

LSB에서는 glibc 등 아주 널리 쓰이는 라이브러리들은 모든 배포판에서 표준적으로 탑재하는 것을 권고합니다. 당연하겠죠? (soname도 지정되어 있습니다. liblsb 어쩌고저쩌고였던 걸로 기억합니다.) 그런데 LSB에서 권고하는 라이브러리들은 가장 많이 쓰이는 필수적인 것들이 되다 보니 상대적으로 자주 쓰이지 않는 라이브러리들은 LSB에서 빠져 있습니다. 당연하겠죠. 배포판에 모든 라이브러리들을 다 설치하라고 할 수는 없는 노릇이니...

그런데 여기서 LSB에 빠진 라이브러리를 링크하는 애플리케이션을 개발하는 회사가 있다고 치면, 이 회사가 LSB 호환성을 지키기 위해서는 LSB에 없는 라이브러리들은 동적으로 링크하면 안되고 정적으로 링크해야 합니다. (당연하겠죠. 그래야 그 라이브러리가 없는 시스템에서도 잘 돌아갈 테니까요.) 이렇게 되면 바이너리 파일이 커지게 되는 등의 원치 않는 부작용들이 생기게 됩니다. 그렇기 때문에 애플리케이션 개발사들은 개발의 복잡성을 줄이기 위해 LSB 호환성보다는 시장점유율이 가장 높은 배포판(레드햇, 수세 등...)을 기준으로 작업을 하게 되는 것이죠. 작은 애플리케이션이라면 LSB호환을 유지하는데 상대적으로 문제가 적습니다. 그렇지만 엔터프라이즈급에서 사용하는 대형 애플리케이션이라면 LSB 호환보다는 시장성을 위주로 선택을 하게 될 수밖에 없고 결국 모든 배포판에서 표준적으로 사용할 수 있는 환경을 만들고자 하는 LSB의 원래 의도를 살리지 못하게 되는 거죠.

충분히 이해는 가지만 상당히 안타까운 현실입니다. 아직은 각 배포판 별로 큰 차이는 많지 않으나 리눅스가 유닉스의 전철을 밟을수도 있지 않을까 하는 우려는 상존하고 있습니다. 그래서 LSB의 역할이 더욱 중요한 것이고요.

blacknblue의 이미지

며칠을 리사파파님이 답해 주시기를 기다렸으나 바쁘신지....
혹시 이 글을 보시면 리눅스에서 다운 된 상황이 위의 윈도우와 같은 상황인지 그리고 그 원인이 어떤부분이라 생각하시는지 말씀 좀 해 주세요.

리사파파님 말씀이 사실이라면 리눅스라는 os 에 뭔가 근본적인 문제점이 있는거 아닌가요?

아니면 상용 os 와의 차이가 심하게 나거나...

둘중 어느것이라 하더래도 음.. 어쨌든 가볍게 볼 사항은 아닌듯 한데....

다즐링의 이미지

저도 기다리고 있습니다..;

상용서비스와 여러가지 인트라넷등으로 아파치를 이용중이지만 아직 단 한껀도 다운된적은 없습니다. ( onLinux ) 물론 2.x는 최근에 쓰기 시작했습니다만.. (2004년 초) 머 별다르게 문제될껕없더군요. os하드웨어 문제로 문제가된적은 있었지요..

------------------------------------------------------------------------------------------------
Life is in 다즐링

offree의 이미지

잘 알지 못하고 짐작으로 말씀드리는 것이지만, 리사파파님이 동일한 상황에서 테스트를 했을 것이라 생각이 됩니다.

우선 ab 등으로 테스트를 하셨겠지요.

그런데, 결과가 리눅스 쪽에서는 서버가 다운되었고, 윈도우 쪽에서는 서비스만 다시 재 가동되고 다운은 되지 않았다 가 결론인 것으로 생각이 됩니다.

리눅스 쪽의 세팅이 문제인지, 리눅스 자체의 프로세스 운용방식의 문제인지, 문제를 찾아내기는 쉽지는 않겠죠.

하드웨어 이외의 것은 모두 다른 상황일테니까요.

아무튼 딱히 무엇이 원인이다 라고 하기는 어려울 것이라 생각이 됩니다.

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

HeartBit의 이미지

angpoo wrote:
가끔 사용자 폭주로 서버가 다운됐다고 자랑하는 싸이트나 뉴스를 보면 정말 가소롭습니다.
심지어 어느 싸이트는 사용자 폭주로 서버 다운됐다는 기사를 내고
실제 홈피에는 http response code는 200 OK로 나오면서
마치 동접자가 많아서 출력되는 에러메시지 페이지 인양 꾸며놓은 곳도 봤습니다.

일종의 intelligent L7 장비에서는 QoS 또는 admission control 차원에서 특정 HTTP request를 해당 장비에서 바로 responde해버리는 경우도 있습니다. "정비 중입니다." 라는지, "~~~한 이유로 ~~~한 상황입니다."라는 안내를 200 code로 응답하는 것은 문제시하기 어렵습니다.

creativeidler wrote:
대부분 데이터베이스 문제입니다.

맞습니다. 적절히 perfomance turing된 시스템의 bottleneck은 가장 backend의 자원이 되는 경우가 대부분입니다.
OoOoOo의 이미지

offree wrote:
잘 알지 못하고 짐작으로 말씀드리는 것이지만, 리사파파님이 동일한 상황에서 테스트를 했을 것이라 생각이 됩니다.

우선 ab 등으로 테스트를 하셨겠지요.

그런데, 결과가 리눅스 쪽에서는 서버가 다운되었고, 윈도우 쪽에서는 서비스만 다시 재 가동되고 다운은 되지 않았다 가 결론인 것으로 생각이 됩니다.

리눅스 쪽의 세팅이 문제인지, 리눅스 자체의 프로세스 운용방식의 문제인지, 문제를 찾아내기는 쉽지는 않겠죠.

하드웨어 이외의 것은 모두 다른 상황일테니까요.

아무튼 딱히 무엇이 원인이다 라고 하기는 어려울 것이라 생각이 됩니다.

리사파파님의 정도의 실력이면 어느정도 정확한 판단을 내렸지 싶네요..

angpoo의 이미지

HeartBit wrote:
angpoo wrote:
가끔 사용자 폭주로 서버가 다운됐다고 자랑하는 싸이트나 뉴스를 보면 정말 가소롭습니다.
심지어 어느 싸이트는 사용자 폭주로 서버 다운됐다는 기사를 내고
실제 홈피에는 http response code는 200 OK로 나오면서
마치 동접자가 많아서 출력되는 에러메시지 페이지 인양 꾸며놓은 곳도 봤습니다.

일종의 intelligent L7 장비에서는 QoS 또는 admission control 차원에서 특정 HTTP request를 해당 장비에서 바로 responde해버리는 경우도 있습니다. "정비 중입니다." 라는지, "~~~한 이유로 ~~~한 상황입니다."라는 안내를 200 code로 응답하는 것은 문제시하기 어렵습니다.

그때 그 페이지를 봤었다면 충분히 공감하셨을텐데..
응답 코드 뿐 아니라 사용자가 많아서 서비스를 제공하지 못한다는 이미지까지 들어있는 페이지가 페이지 새로고침할때마다 매번 한번도 빼지않고 순간적으로 떴었습니다. 그것도 새벽이었는데 내내 그랬습니다.
정말 사용자가 많아서 그런거라면 응답이 늦거나 가끔가다 한번은 제대로된 페이지를 보여줬겠죠.