특히 WordPress와 같은 비대해진 어플리케이션에서는 서버의 메모리 할당 제한에 직면하는 경우가 종종 있지만 “풀에 메모리를 할당할 수 없습니다”라는 문제가 발생하여 정보를 추적하는 데 어려움을 겪지는 않았습니다.
이게 무슨 뜻인지 아는 사람?더 많이 하려고 했는데memory_limit성공하지 못하고어플리케이션도 크게 변경하지 않았습니다.어느 날 문제가 없었고 다음 날 이 오류가 발생했습니다.
질문에 대한 답변
TTL을 0으로 설정하면 메모리가 부족하면 APC가 모든 캐시를 플래시합니다.에러는 발생하지 않게 되었지만 APC의 효율은 크게 저하됩니다.“내 일을 하고 싶지 않다”는 결정은 위험도 문제도 없습니다.APC는 그런 식으로 사용되는 것이 아닙니다.가장 많이 액세스한 페이지가 만료되지 않도록 충분히 높은 TTL을 선택해야 합니다.APC가 캐시를 플래시할 필요가 없도록 충분한 메모리를 제공하는 것이 가장 좋습니다.
매뉴얼을 읽고 ttl의 사용법을 이해하면 됩니다.http://www.php.net/manual/en/apc.configuration.php#ini.apc.ttl
해결책은 APC에 할당된 메모리를 늘리는 것입니다.이를 수행하려면 apc를 늘립니다.shm_size 입니다.
APC가 공유 세그먼트 메모리를 사용하도록 컴파일된 경우 운영체제에 의해 제한됩니다.각 세그먼트의 시스템 제한을 표시하려면 다음 명령을 입력합니다.
sysctl -a
grep -E "shmall shmmax" 더 많은 메모리를 할당하려면 파라미터 apc를 사용하여 세그먼트 수를 늘려야 합니다.shm_module을 클릭합니다.
APC가 mmap 메모리를 사용하는 경우 제한이 없습니다.메모리 용량은 여전히 동일한 옵션 apc에 의해 정의됩니다.shm_size 입니다.
서버에 메모리가 부족하면 filters 옵션을 사용하여 액세스 빈도가 낮은 php 파일이 캐시되지 않도록 합니다.
단, TTL 0은 사용하지 마십시오.
c33s에서 설명한 바와 같이 apc.php를 사용하여 설정을 확인합니다.apc 패키지에서 웹 폴더로 파일을 복사하고 브라우저를 가리킵니다.무엇이 실제로 할당되어 있고 어떻게 사용되는지 알 수 있습니다.그래프는 시간 후에도 안정된 상태를 유지해야 합니다.새로고침 때마다 완전히 변경되면 설정이 잘못되었음을 의미합니다(APC가 모든 것을 플러시합니다).APC가 실제로 보안 마진으로 사용하는 것보다 20% 더 많은 RAM을 할당하고 정기적으로 확인합니다.
32MB만 허용하는 기본값은 터무니없이 낮습니다.PHP는 서버가 64MB이고 대부분의 스크립트가 페이지당 하나의 php 파일을 사용할 때 설계되었습니다.오늘날 Magento와 같은 솔루션에는 10,000개 이상의 파일(APC에서는 60Mb까지)이 필요합니다.대부분의 php 파일이 항상 캐시되도록 충분한 메모리를 확보해야 합니다.이것은 낭비가 아닙니다.파일 캐시에 대응하는 raw php를 두는 것보다 opcode를 ram에 유지하는 것이 더 효율적입니다.오늘날에는 24GB 메모리를 탑재한 전용 서버를 월 $80으로 구입할 수 있습니다.따라서 몇 GB의 메모리를 APC에 할당하는 것을 주저하지 마십시오.24GB 중 2GB를 5Magento 스토어와 40개까지의 워드프레스 웹사이트를 호스팅하는 서버에 저장하면 APC는 1.2를 사용합니다.GB. Magento 설치의 경우 64MB, 일부 플러그인이 있는 WordPress의 경우 40MB를 카운트합니다.
또, 같은 서버에 개발 Web 사이트가 있는 경우.캐시에서 제외합니다.
이 문제가 있는 분에게는 .ini 설정을 지정해 주세요.특히 apc.mmap_file_mask 설정.
파일 백업 mmap의 경우 다음과 같이 설정해야 합니다.
apc.mmap_file_mask=/tmp/apc.XXXXXX /dev/zero에서 직접 mmap을 수행하려면 다음을 사용합니다.
apc.mmap_file_mask=/dev/zero POSIX 준거의 공유 메모리 백업 mmap 의 경우는, 다음을 사용합니다.
apc.mmap_file_mask=/apc.shm.XXXXXX 솔루션:
- apc.ttl=0
- apc.shm_size=필요한 모든 것
편집 개시
경고!
@bokan은 여기에 경고를 추가해야 한다고 나에게 지시했습니다.
ttl이 0인 경우 캐시된 모든 항목을 즉시 삭제할 수 있습니다.따라서 캐시 크기가 2mb, ttl이 0인 경우 캐시 내의 데이터는 항상 덮어쓰기되기 때문에 apc는 사용할 수 없습니다.
ttl을 낮춘다는 것은 캐시가 가득 찰 수 없고 교체할 수 없는 항목만 있다는 것을 의미합니다.
따라서 ttl과 캐시 크기 사이에서 적절한 균형을 선택해야 합니다.
제 경우 캐시 사이즈가 1GB이기 때문에 충분했습니다.
편집 끝
centos 5에서 php 5.2.17과 같은 문제가 발생하여 캐시 크기가 작고 캐시해야 할 php 파일이 많을 때 ttl 파라미터가 “높음”(7200 등)인 경우 캐시가 매우 빠르게 채워지고 apc는 캐시 내의 모든 파일이 여전히 ttl에 맞기 때문에 삭제할 수 있는 파일을 찾을 수 없습니다.
메모리 크기를 늘리는 것은 부분적인 해결책일 뿐이며 캐시 용량이 꽉 차서 모든 파일이 ttl 내에 있는 경우에도 이 오류가 발생합니다.
따라서 ttl을 0으로 설정하여 apc가 캐시를 가득 채우고 apc가 새로운 데이터를 위해 메모리를 클리어할 가능성이 있습니다.
도움이 되기를 바라다
편집: 도 참조:http://pecl.php.net/bugs/bug.php?id=16966
다운로드하고 당신은 좋은 도표처럼 당신의 캐시 사용 모습을 하고 있는 apc.php을 추출하http://pecl.php.net/get/APC.
IMO, apc.php 스크립트를 실행하는 것은 문제가 무엇인지 이해하는 데 중요합니다.이것에 의해, 캐시의 사이징을 올바르게 실시할 수 있게 되어, 현시점에서는 문제가 해결된 것 같습니다.
저 같은 신입사원에게 이러한 자원은 다음과 같은 도움이 되었습니다.
위의 c33에서 권장하는 변경을 하기 위한 apc.ini 파일 검색 및 권장량 설정:http://www.untwistedvortex.com/optimizing-tuning-apc-alternate-php-cache/
apc.ttl이란 무엇입니까?http://www.php.net/manual/en/apc.configuration.php#ini.apc.ttl
apc를 이해하다shm_size는 http://www.php.net/manual/en/apc.configuration.php#ini.apc.shm-size 입니다.