KLDP apache / php update
글쓴이: 김정균 / 작성시간: 일, 2007/09/23 - 8:19오후
KLDP.ORG 서버의 apache (1.3.39) 와 PHP (5.2.4)가 업데이트 되었습니다.
PHP 의 경우 5.2.4 에도 포함되어 있는 보안버그 CVE-2007-4783, CVE-2007-4840가 픽스되어 있습니다. 또한, KLDP 의 druapal 에서 문제가 되었던 opcode cache 문제 (http://bugs.php.net/bug.php?id=38878)의 픽스를 해 보았습니다. Zend VM 을 뜯어 고친일이라서 패치를 공유하더라도 빌드시에 해 줘야 할 일이 있어 공유하기 쉽지 않네요. (그나마 꽁수라서 제대로 한 것이라고 보장도 못하고.. 그래도 PHP 에서 고치지 않겠다고 한 일이라서 이렇게 나마.. 패치는 안녕 리눅스의 PHP 5.2.4의 source rpm 에서 구할 수 있습니다.)
이제 drupal 업그레이드 시에
function name ($vari = array () { }이런 함수를 일일이
function name ($vari = NULL) {
$vari = ( $vari === NULL ) ? array () : $vari;
}와 같이 고칠 필요는 없어진 것 같습니다. :-)
또한, 추석 연휴중 새벽에 불시적으로 장비 교체가 있을 수 있습니다. EMPAS 에서 제공받은 dual core 장비 (X3550) 로 이전 준비중이니 참고 하시기 바랍니다.
관리자 주제:
댓글
drupal 5.2로의
drupal 5.2로의 업그레이드도 준비해야겠네요. 안그래도 저 문제 때문에 full 업그레이드는 못하고 패치만 했었는데... 저희가 처음 5.x로 업그레이드했을 때 온라인 사용자 수가 이상하게 표시되어서 김정균님이 수정했던 부분도 5.2에서 다른 사람이 수정하여 반영했다고 하니 5.2로 업그레이드하는데 문제는 없을 것 같습니다.
아. PHP opcode fix 는
아. PHP opcode fix 는 네오위즈 박상진님께서 해 주셨습니다. :-)
upstream 으로는
upstream 으로는 어떻게... 다른 방법이 없는 것일까요? 버전업될때마다 작업하는 것도 만만치 않은 일일텐데 말이죠. -_-;
PHP 개발자의 생각이
PHP 개발자의 생각이 바뀌기 전에는 힘들 듯 싶어, 네오위즈도 자체 처리 한 것입니다. 뭐 혹시 모르죠. drupal 같은 곳에서 우루루 몰려가서 해 달라고 조르면.. 어떨지 ㅋㅋ
이게, Zend VM 을 패치하는 거라서.. 패치하고 나서 몇몇 header file 을 재 생성 해 줘야 하는 문제가 있어서 패치 후에, Zend directory 에서 zend vm type 을 지정하는 스크립트를 한번 돌려줘야 합니다.
cd Zend
php zend_vm_gen.php --with-vm-kind=CALL
zend VM type 이 기본값으로 CALL 인데, CALL 이 성능이 가장 않좋고, GOTO 가 가장 좋다고 하는데, 이참에 GOTO 로 바꿔서 하려고 하다 보니, 빌드가 안되더군요. 그래서 그냥 일단 CALL 로 가기는 했습니다만..
뭐 하여튼.. upstream 이 쉽지는 않을 듯.. 그리고 중요한 것은 패치한 방법이 좀 구리다는 것이죠. reference 로 하던 것을 copy 로 해 버렸으니..
정균님께 궁금한것이 있습니다.
apache 1.3.39 를 쓰신다고 하셨는데
굳이 1.3.x 버전을 선택하신것은 어떤 특별한 이유가 있는지 궁급합니다.
하늘은 스스로 삽질 하는 자를 삽으로 팬다.
------------------------------------------------
http://glay.pe.kr
--------------- 절취선 ------------------------
하늘은 스스로 삽질하는 자를 삽으로 팬다.
http://glay.pe.kr
prefork model 을
prefork model 을 사용함에 있어 굳이 apache 2.x 와의 차이가 별로 없으니까요. 그리고 몇가지 이유가 있는데,
1. AnNyung Linux 에서 기본 지원되던 것이 1.x 라 2.x 로 jump 시의 관리 문제 해결 지원이 귀찮아서 :-)
2. 위에서 밝혔듯이 굳이 업그레이드 필요성을 못느껴서..
3. 1.3 에서만 되는 모듈이 존재
4. 제일 중요한 것인데.. 제가 apache2 에 관심을 가졌을 때 당시 PHP apache2 SAPI 가 굉장히 불안한 관계로 포기하고 현재까지 옴..
뭐 이정도 입니다. ^^; 그래도 가장 결정적인 이유는.. 굳이 apache 2 로 가야할 필요성을 아직 못느끼기 때문이겠죠.
제가 테스트 해 본
제가 테스트 해 본 결과는 eAccelerator 관련 이슈 같습니다.
아마, http://eaccelerator.net/ticket/34 과 관련 있지 않나 생각됩니다.
APC로 했을 경우 발생하지 않더군요.
에러 메세지는,
[error] [client 127.0.0.1] PHP Fatal error: Allowed memory size of 16777216
또는
[notice] child pid 43612 exit signal Segmentation fault (11)
이었습니다.
6.0? 인가 APC가 기본적으로 포함된다는 얘기도 들은 것 같은데, eAccelerator를 써야하는 특별한 이유가 없다면 이걸로 갈아타는 것이 좋을 듯합니다.
참 사용한 버젼은,
httpd-2.2.4, php-5.2.4, eaccelerator-0.9.5.2, APC-3.0.14
입니다.
APC 는 opcode 를
APC 는 opcode 를 사용하지 않습니다. 이 버그는 opcode 를 사용하는 경우에만 발생합니다. 현재 opcode 를 사용하는 cache 는 eAccelerator 와 Zend Performence 밖에 없을 겁니다. http://eaccelerator.net/ticket/34 와는 관련이 없습니다. opcode 를 사용하느냐 안하느냐에 따라 성능 차이가 꽤 나지요.
인용:APC 는 opcode 를
opcode를 사용한다는 뜻이 opcode를 수정해서 추가적인 optimizing을 한다는 뜻으로 이해해도 되겠습니까? APC도 opcode를 사용은 하니까요.
zend engine을 hook 해서 compile된 opcode를 받아서 쓰는 프로그램이 원래 없던 동작을 일으킨 것이기 때문에 이것을 버그라고 하기엔 무리가 있는 것 같습니다. 만약에 eAccelerator의 optimizer를 껐을 때 정상동작했다면 (잘 설계가 되었다는 가정하에) 좀 더 그렇다고 할 가능성이 있겠지만 역시 버그는 아닙니다. 물론 여러 opcode cache program을 위해 협조해 준다면 고맙겠지만 이미 대규모 사이트에서 검증된 프로그램이 PECL에 공식적으로 있는 상황이고 (아마도) 바뻐 죽겠는데 배포하지도 않은 프로그램을 위해서 그런 수고를 감수할까요? 더구나 (잘 설명해 줬으면 좋았겠지만) 짐작컨데 opcode를 수정하는 것은 엔진 설계 방향과 맞지 않을 수도 있고요.
SMP 환경에서 segfault 난 것이 관계없나요?
facebook에서 기여한 pthread mutex lock을 써서 ab로 phpPgAdmin에 접속해서 간략히 측정해 보니 10% 안 되게 차이나네요. 옵션을 조정해서 튜닝을 좀 한다면 차이는 더욱 줄어들 것 같습니다.
그래서 현재 제대로 동작하고 앞날이 창창한 APC에 한표입니다.
opcode optimizing 문제가
opcode optimizing 문제가 아니라 opcode caching 의 문제입니다. opcode optimizing 과는 상관이 없습니다. SMP 환경과도 상관이 없고.. 말 주변과 정확한 지식이 제대로 없어서 전달이 될지는 모르겠지만, php 에서 reference 로 처리한 것을 E.A 가 변수라고 생각을 하고 건드리면서 발생을 하는 문제입니다. 이에 대한 것은
http://bugs.php.net/bug.php?id=38878
를 참조 하시면 대충 설명이 되어 있습니다. 또한, modestcode 님의 의견대로 caching 의 문제라고 볼 수 는 있습니다만, 모듈 구조의 인터페이싱에 대한 문제도 되기 때문에 제기를 한 것이죠. 즉, php 에서 고쳐주지 않으면 안되는 문제라는 거죠. (뭐 다른 방법이 있을지는 모르겠지만..) 그나마 버그 리포팅을 했던 이유가 Zend Performance Suit 에서도 동일한 버그가 발생이 되었고, PHP 개발자가 Zend 사에 근무하는 사람이 많기 때문에 고쳐주기를 바랬을 뿐입니다.
뭐, 현재 이 문제를 자체적으로 픽스한 마당에 굳이 EA 를 APC 로 바꾸는 것은 좀 더 생각해 봐야 겠습니다.
인용:opcode optimizing
APC가 opcode를 사용하지 않는다고 해서 제가 optimizing 문제를 꺼냈는데요, 다시 말씀 드리면 추가 적인 optimizing을 하지 않을 뿐이지(예전에 하다가 이젠 안 하지만) opcode caching을 안 하는 것이 아닙니다. 그리고 이 문제를 잘 해결하고 있습니다. eAccelerator로서는 optimizer 설정을 끌 수도 있기 때문에 기본적인 caching 문제로 제대로 처리할 필요가 있습니다.
좀 더 쉽게 드러날 수 있을 뿐 근본적으로 상관없다는데 동의합니다. 같은 스크립트에서 반복 호출 했을 경우도 마찬가지니까요.
그리고 위에서 Allowed memory size 관련 오류 난 것은 좀 더 조사를 해 봐야겠지만 eAccelerator의 compression 설정을 하지 않은 경우 php의 memory_limit과 관련해서 문제가 된 것 같습니다.
이런 경우가 php script engine 자체로 충분히 빠르게 하기 위해서 최적화한 예로 생각합니다. 테스트 해 보지 않았지만, deep copy를 할 경우 opcode cache 프로그램을 사용하지 않는 사이트들이 성능에 영향을 받을 것 같습니다. 그러기에 이것은 opcode caching program이 처리해야 할 문제라고 생각하고 실제로 ZEND_RECV_INIT 관련해서 APC에서 따로 처리하고 있습니다.
제가 알기론 opcache프로그램을 위해 모듈 구조의 인터페이싱에 대해서 정의한 적이 없습니다. 그러기에 유효하지 않습니다. 그리고 PHP에서 고쳐주지 않으면 안 된는 문제가 아닙니다. 언급했듯이 APC를 참고할 수 있을 것 같습니다.
Zend Suite?를 사용하지 않고 custom compile한 binary에 대한 Zend사의 입장이 궁금하네요. 이것은 확실히 Zend사에 리포트를 해야할 사항으로 봅니다. Redhat사 제품이 mainline kernel에서 돌아가지 않는다고 커널 버그질라에다가 리포트하는 경우랑 비슷한 것 같습니다.
mastcode 님과의
mastcode 님과의 커뮤니케이션 중에
http://eaccelerator.net/ticket/34
http://bugs.php.net/bug.php?id=38878
상황이 짬뽕이 된 것 같습니다. 현재 KLDP 에서 http://eaccelerator.net/ticket/34의 문제는 종료된 상태입니다. 이 문제가 SMP 상황에서의 문제라고 볼 수 있을지 모르겠지만, single core 에서도 발생을 하는 문제입니다. (그래서 SMP 랑 관련이 없다고 한 것이고요.) 또한, Allowed memory size 관련 오류는 이 버그 상황에서도 case by case 입니다. 이 버그 자체가 딱 정확한 상황을 말하고 있는 것이 아니기 때문입니다. 그리고 KLDP 운영에 별 상관이 없기도 하고요.
그렇다면 http://bugs.php.net/bug.php?id=38878를 놓고 얘기해야 하는데, (이 경우는 http://eaccelerator.net/ticket/34와는 완전히 다른 상황입니다.) 얘기야 위에서 어떤 버그이고, 버그를 받아주지 않아서 수정을 했다고 한 상황입니다.
레드햇 커널을 비유했는데, 이건 좀 너무 부풀려 진 것 같고요. 모듈을 사용할 수 있도록 되어 있는 인터페이스에서 모듈을 이렇게 만들면 성능을 더 높일 수 있다면 충분히 건의할 수 있는 내용이라 생각하여 건의를 한 것입니다. (모듈 인터페이스 언급한 내용이었죠.) 다만, 반응이 mastercode 님이 말씀하신대로
이걸 해결하려면 EA나 ZP를 사용하지 않을 경우 성능이 떨어질 수 있기 때문에 고치기 힘들다는 반응이었다면 수긍이 되지만, 그들은 그냥 EA에서 발생한다는 글만 보고.. 이건 우리랑 관련이 없다는 태도로 댓구하는 것이 심히 보기 싫다는 것입니다. 버그 보고를 잘 읽어 보시면, 예전 mmcache 를 만든 사람(드미트리였나?? 뭐 하여튼 지금 mmcache 개발을 관두고 Zend에 입사했죠.)은 '이 버그를 알고 있다. 시간나면 수정해 보겠다.' 라고 자기가 asign을 했는데, 다른 개발자가 무시하고 bogus 로 변경을 해 버렸습니다.
그리고 APC 는.. 제가 코드를 보지 않아서 잘 모르겠는데, 예전에 저희 회사에서 php cache module 을 비교 분석하여 벤치마킹한 적이 있었는데, 직접 하신 분 말씀이.. APC는 캐싱을 할때 serialize 를 해서 캐싱을 하고, 불러올때 unserialize를 하기 때문에 over head가 너무 커서 포기했다고 하는군요. 지금도 그럴지는 모르겠습니다만.. (저도 APC 테스트 해 본것이 2년전이라서.. ^^)
인용:이걸
거기 분이 지침을 언급했듯이, 그런 선상에서 반응을 보인 것 같습니다.
시간이 많이 흘렀으니, 다시 벤치마킹해 보는 것도 괜찮을 것 같습니다. pthread lock을 쓰고 stat도 끄고 apc_compile_file 을 잘 이용하면 좋은 결과가 나올 것도 같은데요.
댓글 달기