2012-10-23 1 views
8

최근에 jemalloc에 ​​대해 알게되었는데, firefox에서 사용하는 메모리 할당 자입니다. 나는 jemalloc을 내 시스템에 통합하려고 시도했다. 새로운 연산자를 삭제하고 memoc과 je_malloc 및 je_free라는 무료 jemalloc을 호출했다. 나는 1 억 개의 할당을 수행하는 테스트 애플리케이션을 작성했다. glibc malloc과 jemalloc을 사용하는 동안 jemalloc을 사용하여 실행하는 것은 CPU 사용률이 꽤 높은 그러한 할당에 더 적은 시간이 걸리며 malloc에 ​​비해 메모리 풋 프린트도 더 큽니다. jemalloc analysis 에서이 문서를 읽은 후 jemalloc은 메모리보다 속도를 최적화하는 기술을 사용하므로 malloc보다 큰 발자국이있을 수 있습니다. 그러나 Jemalloc을 사용하여 CPU 사용량에 대한 정보를 얻지 못했습니다. 나는 아래에 주어진 세부 사항을 다루는 다중 프로세서 머신에 대해 작업하고 있다고 말하고 싶다.glibc malloc과 비교했을 때 jemalloc의 CPU와 메모리 사용량

프로세서 : 11 VENDOR_ID : GenuineIntel CPU 가족 6 모델 : 44 모델명 : 인텔 (R) 제온 (R) CPU의 X5680의 @ 3.33GHz을 스텝 2 의 CPU 메가 헤르츠 : 3325.117 캐쉬 크기 : 12,288킬로바이트 물리적 ID : 1 형제 12 코어 ID : 10 개 CPU 코어 6 apicid 53 FPU : 예 fpu_exception : 예 CPUID 레벨 : 11 WP : 예 플래그 : FPU VME 드의 PSE TSC의 MSR의 PAE를 MCE의 CX8의 APIC SEP MTRR PGE MCA CMOV 확실 PSE36의 CLFLUSH의 DTS의 ACPI MMX fxsr SSE SSE2의 SS HT TM 콜 NX pdpe1gb rdtscp LM CONSTANT_TSC IDA NONSTOP_TSC 아라 PNI는 EST TM2 SSSE3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm 을 ds_cpl VMX의 SMX 모니터링 밉스 : 6649.91 CLFLUSH 크기 : 64 cache_alignment 64 개 주소 크기 : 40 비트, 실제 48 비트 가상 전원 관리 : [8]

I가 사용하고 가기 -c -b -d 1.10 -p 24,670 | awk -v time = $ TIME '{print time, ",", $ 9}'은 CPU 사용량을 추적합니다.

Jemlloc을 통합하는 동안 비슷한 경험을 한 사람이 있습니까?

감사합니다.

답변

1

이 질문은 실제 솔루션의 경우 서로 다른 하드웨어/환경/사용 시나리오에서 다른 사람들이 발견 한 것과 관련이 없으므로 여기에 속하지 않을 수 있습니다. 당신은 목표 시스템을 테스트하고 당신에게 맞는 것을보아야합니다.

높은 메모리 풋 프린트의 경우 컴퓨터 과학에서 가장 고전적인 성능 최적화 중 하나는 시간 - 메모리 절충입니다. 즉, 인스턴트 조회를위한 특정 결과를 나중에 캐싱하고 잦은 재 계산을 방지합니다. 또한 아마도 훨씬 더 복잡한 것이기 때문에 더 많은 내부 부기가있을 것입니다. 이러한 종류의 절충안은 다소 낮은 수준의 모듈과 널리 사용되는 코어 모듈의 변형을 선택하는 경우 다소 예상됩니다. 일반적으로 은색 총알이 없으므로 사용 특성에 따라 특성 특성을 맞추어야합니다.

Google의 TCMalloc을 보길 원할 수도 있습니다. Jemalloc이 일반적으로 약간 더 성능이 좋고 시간이 지남에 따라 힙 조각화가 덜 발생한다고 생각합니다.

+0

의견을 보내 주셔서 감사합니다. 누군가 다른 멀티 프로세서 시스템에서 비슷한 관찰을했는지 알아 내려고했습니다. 정확한 성능은 하드웨어에 완전히 의존한다는 것에 전적으로 동의하지만 CPU 사용 패턴이 동일해야하는지 궁금합니다. 예를 들어 jemalloc 멀티 프로세서 환경에서. – deb

1

Aerospike는 NoSQL 데이터베이스에 jemalloc을 구현하고 약 1 년 전에 v3.3.x로 공개적으로 구현을 발표했습니다.바로 Psi Mankoski는 왜 우리가 그 이유와 방법을했는지와 GlibC malloc과 비교하여 성능 향상을 발표했습니다. an article on High Scalability.

RAM 조각화를 최소화하기 위해 jemalloc의 디버깅 기능을 사용할 수 있었던 방식 때문에 실제로 RAM 사용률이 감소했습니다. 프로덕션 환경에서 서버 % Free Memory는 종종 "뾰족한 그래프"였으며 JEMalloc을 구현하기 전에 54 %까지 높이 올랐습니다. 구현 후 4 개월 분석 기간 동안 RAM 사용량 감소를 확인할 수 있습니다. RAM %의 여유 메모리는 서버 노드에 따라 ~ 22-40 % 사이에서 움직이며 훨씬 더 예측 가능합니다.

프리엣 (Preet)에 따르면 시간이 지남에 따라 조각화가 훨씬 적어 RAM 사용률이 낮아졌습니다. Psi의 기사는 그러한 진술 뒤에 "푸딩에 대한 증거"를 제시합니다.

19

한 명의 현명한 사람이 CppCon에서 성능에 대해 추측 할 필요가 없다고 말했습니다. 대신 그것을 측정해야합니다. 멀티 스레드 Linux 응용 프로그램에서 jemalloc을 사용하려고했습니다. 그것은 (TCP/IP를 통해) 사용자 지정 응용 프로그램 수준 프로토콜 서버였습니다. 이 C++ 응용 프로그램은 JNI를 통해 Java 코드를 사용했습니다 (Java를 사용한 시간은 5 %, C++ 코드는 95 %였습니다). 프로덕션 모드에서 두 개의 응용 프로그램 인스턴스를 실행했습니다. 각각 150 개의 스레드가있었습니다. 72 시간 동안 실행 한 후 glibc은 900M의 메모리를 사용했으며 jemalloc은 2.2G의 메모리를 사용했습니다. 중요한 CPU 사용량 차이를 보지 못했습니다. 실제 실적 (평균 클라이언트 요청 제공 시간)은 두 경우 모두 거의 같았습니다. 그래서, 내 테스트에서 glibc은 훨씬 더 그 jemalloc했다. 물론, 그것은 내 응용 프로그램에 따라 다릅니다. 결론 : 응용 프로그램 메모리 관리가 조각화 때문에 효과적이지 않다고 생각할 이유가 있다면, 설명 된 것과 비슷한 테스트를 만들어야합니다. 특정 요구에 맞는 신뢰할 수있는 유일한 정보 소스입니다. jemalloc이 항상 더 나은 경우 glibc, glibcjemalloc의 공식 할당 자입니다. glibc이 항상 더 나은 경우 jemalloc이 중지됩니다. 경쟁자가 오랜 시간 동안 평행하게 존재할 때, 그것은 각자가 그것의 자신의 사용법 틈새를 가지고 있다는 것을 의미합니다.

0

나는 간단한 NoSQL 데이터베이스를 개발 중이다. 내가 jemalloc, 성능 감소하지만 메모리 "분열"을 사용하면 표준 malloc에 ​​


(https://github.com/nmmmnu/HM4)

jemalloc도 감소한다. Jemalloc은 피크에서 더 적은 메모리를 사용하는 것으로 보이지만 차이는 5-6 %입니다.

메모리 조각화의 의미는 다음과 같습니다.

  • 우선 나는 키 값 쌍의 제비 (메모리 5-7 GB)
  • 가 그럼 난 메모리 사용량보고를 할당합니다.
  • 그런 다음 모든 실행 파일과 실행 파일을 할당 해제합니다. 할당 순서는 할당 취소 순서와 동일합니다.
  • 마지막으로 메모리 사용량을 다시 확인합니다.

표준 malloc에서 ussage는 거의 피크와 같습니다. (나는 특히 mmap 메모리를 검사했고 아무 것도 없다).

jemalloc 사용은 최소화되어 있습니다.


보너스 정보 - tcmalloc 내가 tcmalloc으로 확인

마지막으로, 그것은 매우 빠른 정말로 - 표준 malloc에 ​​이상 아마 10 개 % 개선.

피크에서 표준 malloc보다 적은 메모리를 소비하지만 jemalloc보다 많습니다.

메모리 조각화에 대해서는 기억이 나지 않지만 jemalloc 결과와는 거리가 멀습니다.