컴파일 및 바이너리 리눅스 배포판 / 패키지의 성능 차이

인터넷에서 많이 검색했는데 정확한 답을 찾지 못했습니다.

바이너리와 함께 제공되지 않고 패키지 (포트)를위한 소스 코드 만있는 젠투 (또는 FreeBSD)와 같은 배포판이 있습니다.

배포판의 대부분은 바이너리 백본 (데비안 등)을 사용합니다.

첫 번째 질문 : 컴파일 된 패키지에서 얼마나 많은 속도 향상을 기대할 수 있습니까? Apache 또는 mysql과 같은 실제 패키지에서 속도를 얼마나 높일 수 있습니까? 즉 초당 쿼리?

두 번째 질문 : 바이너리 패키지는 첫 번째 AMD 64 비트 CPU 이후에 도입 된 CPU 명령을 사용하지 않는다는 것을 의미합니까? 32 비트 패키지를 사용하면 패키지가 386에서 실행되며 기본적으로 최신 CPU 명령을 대부분 사용하지 않습니까?

추가 정보:

• 데스크탑이 아니라 서버 환경에 대해 이야기하고 있습니다.
• 컴파일 시간에 신경 쓰지 않습니다.
• 더 많은 서버가 있으므로 소스 코드 패키지를 사용하는 데 15 % 이상의 속도 증가가 필요합니다
• 화염 전쟁은하지 마십시오.

성능 차이는 거의 모든 경우에 최소한이며 가치가 없습니다. 소스 배포판을 사용해야하는 좋은 이유 (gentoo의 bindist 시스템이 허용하는대로 자신의 바이너리 꾸러미를 굴리는 동안)는 다음과 같습니다 :

• 고유 한 사용자 지정 패치 배포
• 커널 커스터마이징
• 자신 만의 업데이트 패키징

이러한 작업을 수행하지 않으면 소스 배포가 필요하지 않습니다. 개인적인 용도로는 바이너리 호환성에 대해 너무 걱정하지 않고 자유롭게 점진적으로 업그레이드 할 수 있기 때문에 매우 편리합니다. 엔터프라이즈 환경에서 자주 볼 수있는 문제는 아닙니다.

자체 RPM 패키지 또는 기타를 만들어 바이너리 배포판으로 이러한 작업을 수행 할 수 있다는 점은 주목할 가치가 있습니다. 관리 오버 헤드는 비슷합니다.

소스에서 컴파일하면 기본적으로 속도가 15 % 증가하지 않습니다. 합리적인 경우에는 5 %까지 추정하기가 쉽지 않습니다. 소스에서 컴파일하면 몇 가지 사항이 있습니다.

• 선호하는 컴파일러 버전을 사용하게됩니다
• AESNI 및 AVX와 같은 이진 배포판 패키지에 사용되지 않는 ISA 확장에서 명령어를 생성하도록 컴파일러에 지시 할 수 있습니다.

그러나 컴파일러는 실제로 어쨌든 실제로 거의 생성하지 않으며 응용 프로그램의 성능을 전체적으로 고려할 때 컴파일러를 사용하면 전체적으로 절약되는 비용이 일반적으로 매우 적습니다. RAM 액세스 (및 대기 시간) 및 디스크 및 장치 대기 시간과 같은 것들이 훨씬 더 큰 요소이므로 실제로 시작해야합니다.

비교적 최근의 Intel 코어 i7 또는 i5에서만 실행되는 사용자 정의 컴파일의 이점을 얻을 수있는 응용 프로그램 에는 많은 벡터 수학을 수행하는 응용 프로그램 과 많은 AES 암호화 및 암호 해독을 수행하거나 많은 임의의 숫자가 필요한 응용 프로그램이 포함됩니다. 인텔 DRBG를 사용하려면 현재이 작업도 수행해야합니다.

이 중 어느 것도 적용되지 않으면 데비안 또는 Red Hat 기반 배포판에 매우 만족할 것이며 유지 관리 오버 헤드가 훨씬 적습니다.

짧은 대답 ... 많은 대규모 및 속도 / 대기 시간에 민감한 응용 프로그램은 표준 Linux 배포에서 실행됩니다. Red Hat, CentOS, Debian, Ubuntu ... 모두 대부분의 경우 잘 작동합니다. 대부분의 이점은 응용 프로그램 튜닝, 표준 커널 및 OS 최적화 및 인프라에서 비롯됩니다.

젠투 는 약간의 최적화를 제공하지만 더 많은 관리 문제, 마인드 쉐어 감소, 공급 업체 및 운전자 지원 감소, 안정성 문제, 조롱 및 잠재적 보안 문제에 대한 문을 엽니 다 .

고주파 금융 거래 환경에서 젠투 기반 서버를 관리했습니다. 젠투에서는 약간의 성능 이점이 있었지만 여전히 Red Hat과 CentOS로 옮겼습니다. 종이에 대한 Gentoo의 장점은 더 똑똑한 하드웨어 선택, 더 나은 서버 제조업체 / 하드웨어 통합 지원, Red Hat 엔지니어의 더 똑똑한 패치 및 커널 우회 와 같은 더 난해한 기술로 쉽게 극복 할 수있었습니다 .

널리 사용되는 응용 프로그램 스택 (LAMP)의 효율성에 문제가있는 경우 서버 하드웨어 (CPU 유형, RAM 레이아웃), 네트워킹 인프라, 모니터링 시스템을 최적화하고 시스템 병목 현상을 식별 할 수 있는지 확인하십시오 이 길을 따라가는.

지금 성능 한계에 도달하고 있습니까?

모든 포인트는 물론 정확합니다. 5 % -15 %의 성능 향상을 달성 할 수 없다는 아이디어, 특히 최신 버전의 GCC에서는 실제로 CPU 아키텍처와 목표로 사용되는 기준선에 얼마나 근접한가에 달려 있습니다. 이진 분포에 대해. ISA 확장을 사용하는 것 외에도 GCC -march = native는 L1 및 L2 캐시 / 라인 크기를 최적화합니다. -flto를 사용하면 특히 CPU에 맞게 올바르게 정렬 된 코드가 훨씬 빨라져 컴파일러가 고려해야 할 모든 것을 알 수 있습니다. [불행히도 일부 패키지는 현재 LTO로 고장났습니다]

또한 march = native 및 LTO 외에도 -Ofast를 사용하여 선택 패키지를 컴파일하면 큰 차이가 생길 수 있습니다.

앞으로 GCCs Graphite 인프라가 안정화되면 더 큰 이익을 얻을 수 있습니다.

그것은 당신이 당신의 시스템에서 원하는 것에 달려 있으며, 실제로 여기에 세 가지 학교가 있습니다 (그리고 이것은 하드웨어와 소프트웨어 모두에 해당됩니다)

첫째, SF에 관한 대부분의 사람들이가는 한 주류는 당신이 알고있는 것이 효과가 있고, 지원 이 필요하며, 지금 그것을 원한다는 것 입니다. 이 경우, Redhat 기반 시스템을 사용하는 것이 좋습니다 (RHEL은 탁월한 지원을 제공하며 centos는 잘 테스트 된 RHEL 배포의 커뮤니티 재 구축입니다). 그러나 최신의 최고를 얻지 못할 것입니다. 많은 경우에 이것은 하드웨어에도 해당됩니다.

두 번째는 '길의 중간'관점으로, 우분투와 같은 중간 지점입니다. 당신은 당신이 원하는 설치 프로그램 (완전한 견고한 안정성의 약간의 비용으로) 새로운 패키지, 원하는 좋은 물건을 .

어떤 경우에는 사람들이 문제를 겪을 수 있지만 최신 패키지가 있고 합리적으로 테스트 됩니다. 우분투에는 많은 증오가 있지만 설치의 용이성과 새로운 패키지 사이의 좋은 절충안입니다. 데비안은 아마도 좀 더 보수적 인 선택 일 것입니다. 요즘에는 대기 시간이 짧은 커널로 우분투를 즉시 설정할 수 있습니다. 나는 우분투와 데비안이 나를 위해 일하는 경향이 있지만 ymmv입니다. 페이스 북 및 구글과 같은 많은 서버 를 배치하는 많은 장소 들이이 옵션을 선택합니다.

마지막으로 소스 기반 배포판이 있습니다. 대부분의 경우 초기 설정은 뒤쪽의 심한 통증입니다. 커널 설정에 실수를 했습니까? 죄송합니다. 몇 시간 동안 재 컴파일하십시오. n00bs 용 설치 프로그램도 없습니다. 최첨단 응용 프로그램과 필요에 따라 컴파일하는 옵션 (예 : 속도 또는 메모리 사용에 대한 최적화 선택 가능) 및 롤링 릴리스가 제공됩니다. 매우 구체적이고 난해한 요구가 있다면 젠투는 훌륭합니다. 수십 개의 시스템을 출시하고 자동화하려는 경우 ... 행운을 빕니다. 소스 기반 배포는 단순히 확장되지 않습니다. 패키지 기반 배포 IMO와 같은 수준에서 많은 유연성, * 일부 ** 추가 속도를 얻을 수 있지만 유지 관리가 불가능합니다. 당신은 아니에요15 %의 추가 속도를 얻을 수 있으며 하드웨어의 컴파일 플래그를 조정하는 데 시간을 낭비하고 무언가를 엉망으로 만들면 정확히 실패한 것을 해결 하는 데 시간을 소비하게됩니다 .

BSD는 별도 의 OS 제품군 입니다. 어떤 사람들은 그들에 의해 맹세합니다 (적어도 하나의 통신 룸은 freebsd 사용자입니다). 그리고 다른 BSD는 다른 초점을 가지고 있습니다. 어떤 경우에는 리눅스와 동일한 종류의 하드웨어 지원이 없을 수도 있지만, 이는 몇 가지 요소에 달려 있습니다.