mysqld 서비스는 ec2 서버에서 하루에 한 번 중지됩니다.
환경 세부 정보:
Server: Amazon ec2 Linux
Web Server: Apache
Web Framework: Django with mod_wsgi
다음으로 mysql_err.log 파일을 찾았습니다.
The InnoDB memory heap is disabled
120823 3:21:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120823 3:21:40 InnoDB: Compressed tables use zlib 1.2.3
120823 3:21:40 InnoDB: Using Linux native AIO
120823 3:21:41 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
120823 3:21:41 InnoDB: Completed initialization of buffer pool
120823 3:21:41 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120823 3:21:41 [ERROR] Plugin 'InnoDB' init function returned error.
120823 3:21:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120823 3:21:41 [ERROR] Unknown/unsupported storage engine: InnoDB
120823 3:21:41 [ERROR] Aborting
시스템 메모리가 버퍼 풀에 메모리를 할당하기에 충분하지 않은 것 같습니다.사용할 때도 동일한 오류가 발생합니다.Amazon ec2 micro instance그래서 저는 그 곳으로 옮겼습니다.small instance어떤 날은 잘 작동하지만 지금은 다시 하루에 한 번씩 고장이 납니다.그것에 대한 영구적인 해결책이 있습니까?중간 인스턴스로 이동할 수 있지만 문제는 수정 여부입니다.좀 줄여볼까요?innodb_buffer_pool_size선호하는 사이즈는 무엇입니까?
의 결과cat /proc/meminfo다음과 같습니다(도움이 될 수도 있음).
MemTotal: 1697824 kB
MemFree: 125744 kB
Buffers: 109704 kB
Cached: 481408 kB
SwapCached: 0 kB
Active: 1212396 kB
Inactive: 266840 kB
Active(anon): 888192 kB
Inactive(anon): 76 kB
Active(file): 324204 kB
Inactive(file): 266764 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 4 kB
Writeback: 0 kB
AnonPages: 888144 kB
Mapped: 15604 kB
Shmem: 144 kB
Slab: 63752 kB
SReclaimable: 53680 kB
SUnreclaim: 10072 kB
KernelStack: 800 kB
PageTables: 16436 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 848912 kB
Committed_AS: 1417140 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 10988 kB
VmallocChunk: 34359725168 kB
DirectMap4k: 1748992 kB
DirectMap2M: 0 kB
OS 버전(이름 -a):Linux ip-10-246-134-149 3.2.21-1.32.6.amzn1.x86_64 #1 SMP Sat Jun 23 02:32:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
는 확했습다니를 확인했습니다.ps aux에 15MB 있는지 및 이 "" "15MB"와 같은지 입니다.httpd해당 시간에 실행 중인 프로세스:
의 결과free -m
total used free shared buffers cached
Mem: 1657 1628 29 0 3 19
-/+ buffers/cache: 1605 51
Swap: 895 875 20
의 결과ps aux
apache 21123 0.1 1.2 394652 20464 ? S 19:35 0:06 /usr/sbin/httpd
apache 21146 0.1 1.2 394280 20796 ? S 19:38 0:06 /usr/sbin/httpd
apache 21152 0.1 1.2 394284 21560 ? S 19:38 0:05 /usr/sbin/httpd
apache 21155 0.2 1.4 396244 24528 ? S 19:38 0:06 /usr/sbin/httpd
apache 21156 0.1 1.1 392552 20344 ? S 19:38 0:06 /usr/sbin/httpd
apache 21157 0.1 1.1 394284 18884 ? S 19:38 0:05 /usr/sbin/httpd
apache 21159 0.1 1.4 396200 25040 ? S 19:38 0:06 /usr/sbin/httpd
apache 21161 0.1 1.2 394856 21724 ? S 19:38 0:06 /usr/sbin/httpd
apache 21162 0.1 1.3 394864 22400 ? S 19:38 0:06 /usr/sbin/httpd
apache 21163 0.1 1.3 394860 22204 ? S 19:38 0:06 /usr/sbin/httpd
apache 21164 0.1 1.1 392560 19204 ? S 19:38 0:06 /usr/sbin/httpd
apache 21165 0.1 1.3 394832 22280 ? S 19:38 0:06 /usr/sbin/httpd
apache 21166 0.1 1.3 395276 22932 ? S 19:38 0:06 /usr/sbin/httpd
apache 21172 0.2 1.4 396320 24820 ? S 19:38 0:06 /usr/sbin/httpd
apache 21174 0.2 1.7 400672 29452 ? S 19:39 0:06 /usr/sbin/httpd
apache 21178 0.1 1.4 400540 25304 ? S 19:39 0:06 /usr/sbin/httpd
apache 21179 0.2 1.6 400580 27856 ? S 19:39 0:06 /usr/sbin/httpd
apache 21184 0.1 1.7 400628 29320 ? S 19:39 0:06 /usr/sbin/httpd
apache 21185 0.1 1.6 397944 27292 ? S 19:39 0:05 /usr/sbin/httpd
apache 21186 0.1 1.5 397960 25648 ? S 19:39 0:05 /usr/sbin/httpd
apache 21187 0.1 1.7 400576 29120 ? S 19:39 0:06 /usr/sbin/httpd
apache 21191 0.1 1.4 400576 24400 ? S 19:39 0:06 /usr/sbin/httpd
apache 21193 0.1 1.4 400536 24940 ? S 19:39 0:05 /usr/sbin/httpd
apache 21194 0.1 1.5 400572 26096 ? S 19:39 0:06 /usr/sbin/httpd
apache 21203 0.1 1.6 400580 28808 ? S 19:39 0:05 /usr/sbin/httpd
apache 21206 0.1 1.7 400584 29732 ? S 19:39 0:06 /usr/sbin/httpd
apache 21207 0.1 1.6 400576 27940 ? S 19:39 0:06 /usr/sbin/httpd
apache 21224 0.1 1.2 400624 20768 ? S 19:39 0:06 /usr/sbin/httpd
apache 21225 0.1 1.6 400576 28468 ? S 19:39 0:05 /usr/sbin/httpd
apache 21226 0.1 1.6 400576 28048 ? S 19:39 0:06 /usr/sbin/httpd
apache 21228 0.1 1.4 400572 23880 ? S 19:39 0:06 /usr/sbin/httpd
apache 21237 0.1 1.5 400628 26124 ? S 19:39 0:06 /usr/sbin/httpd
apache 21265 0.1 1.6 400536 28592 ? S 19:39 0:06 /usr/sbin/httpd
apache 21276 0.1 1.2 400544 21456 ? S 19:39 0:05 /usr/sbin/httpd
apache 21277 0.1 1.3 400624 22676 ? S 19:39 0:05 /usr/sbin/httpd
apache 21278 0.1 1.6 400536 27360 ? S 19:39 0:06 /usr/sbin/httpd
apache 21282 0.1 1.4 400612 24996 ? S 19:39 0:06 /usr/sbin/httpd
apache 21292 0.1 1.4 400532 24780 ? S 19:39 0:05 /usr/sbin/httpd
apache 21302 0.2 1.2 400540 21332 ? S 19:39 0:06 /usr/sbin/httpd
apache 21303 0.1 1.3 400628 22228 ? S 19:39 0:06 /usr/sbin/httpd
apache 21305 0.2 1.2 400536 21116 ? S 19:39 0:06 /usr/sbin/httpd
apache 21306 0.1 1.3 400572 22380 ? S 19:39 0:06 /usr/sbin/httpd
apache 21307 0.1 1.1 397956 20056 ? S 19:39 0:05 /usr/sbin/httpd
apache 21308 0.1 1.2 400624 21520 ? S 19:39 0:06 /usr/sbin/httpd
apache 21319 0.1 1.1 400540 19468 ? S 19:39 0:05 /usr/sbin/httpd
apache 21320 0.1 1.3 400628 22712 ? S 19:39 0:05 /usr/sbin/httpd
apache 21335 0.1 1.0 400540 17236 ? S 19:39 0:05 /usr/sbin/httpd
apache 21336 0.1 1.3 400628 22188 ? S 19:39 0:06 /usr/sbin/httpd
apache 21352 0.1 1.1 394276 18972 ? S 19:40 0:04 /usr/sbin/httpd
apache 21356 0.1 1.1 394280 19028 ? S 19:40 0:05 /usr/sbin/httpd
apache 21358 0.1 1.1 394280 19004 ? S 19:40 0:05 /usr/sbin/httpd
apache 21361 0.2 0.7 400452 12632 ? S 19:40 0:06 /usr/sbin/httpd
apache 21610 0.2 1.6 400536 27660 ? S 19:46 0:06 /usr/sbin/httpd
apache 21643 0.2 1.3 400156 23272 ? S 19:55 0:04 /usr/sbin/httpd
apache 21647 0.2 1.0 400544 17556 ? S 19:57 0:05 /usr/sbin/httpd
apache 21654 0.2 1.5 400188 26884 ? S 19:58 0:05 /usr/sbin/httpd
apache 21719 0.3 1.9 400192 32264 ? S 20:14 0:03 /usr/sbin/httpd
apache 21725 0.2 2.0 400044 35340 ? S 20:15 0:03 /usr/sbin/httpd
apache 21738 0.0 0.8 257648 13792 ? S 20:26 0:00 /usr/sbin/httpd
httpd 프로세스가 왜 이렇게 많은지 아시는 분 계신가요?
사용 가능한 RAM의 50%를 테스트에 사용:
innodb_buffer_pool_size를 매우 낮게 줄여서 다음과 같은 도움이 되는지 확인할 수 있습니다.
#/etc/my.cnf
innodb_buffer_pool_size = 1M
경험에 따르면 메모리 부족 테스트를 위해 innodb_buffer_pool_size를 사용 가능한 RAM의 50%로 설정합니다.이는 서버와 MySQL InnoDB를 제외한 모든 것을 시작한다는 의미합니다.RAM 용량을 확인합니다.그런 다음 InnoDB에 50%를 사용합니다.
한 번에 여러 개의 메모리 부족 설정을 시도하려면:
웹 서버와 같이 해당 서버에 있는 다른 모든 것이 범인일 가능성이 높습니다.
아파치?
Apache 및/또는 다른 웹 서버를 사용하고 있습니까?그렇다면 RAM 사용량을 줄이십시오.예를 들어 Apache conf에서 다음과 같은 낮은 RAM 설정을 고려합니다.
StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5
다음과 같이 요청을 제한합니다.
MaxRequestsPerChild 300
그런 다음 Apache를 다시 시작합니다.
mod_wsgi:
mod_python과 함께 Apache를 사용하는 경우 mod_wsgi와 함께 Apache로 전환합니다.
핌플러:
만약 아직도 그런 일이 일어난다면, 아마도 당신의 장고는 꾸준히 성장하고 있을 것입니다.Pymppler를 사용하여 Django 메모리 프로파일링을 시도합니다.
SAR:
하루에 한 번 실패한 다음 주에 한 번 실패한 보고서는 매일 또는 매주 실행되는 일종의 cron 작업을 가리킬 수 있습니다.예를 들어 RAM을 많이 사용하는 배치 프로세스나 데이터베이스 덤프 등이 있을 수 있습니다.
RAM 사용을 추적하고 MySQL이 종료되기 전 몇 시간 동안 RAM 급증을 찾으려면 훌륭한 도구인 SAR을 살펴보십시오. http://www.thegeekstuff.com/2011/03/sar-examples/
innodb_message_pool_size = 기본 메모리의 60-80% 미만)을 줄여야 합니다.
Innodb 오류에 대한 솔루션:
110603 7:34:15 [ERROR] Plugin ‘InnoDB’ init function returned error.
110603 7:34:15 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
110603 7:34:15 [ERROR] Unknown/unsupported storage engine: InnoDB
110603 7:34:15 [ERROR] Aborting
10603 7:34:15 [Note] /usr/sbin/mysqld: Shutdown complete
I moved the ib_logfile0 and ib_logfile01 to bak and start Mysql again. Now this time, it is working fine
[root@xxx mysql]# mv ib_logfile0 ib_logfile0-bak
[root@xxx mysql]# mv ib_logfile1 ib_logfile1-bak
출처: http://www.onaxer.com/tag/error-plugin-innodb-init-function-returned-error/
다른 사람들이 언급했듯이, 문제는 당신의 시스템에 RAM이 부족하고 그로 인해 MySQL이 폭발하고 있다는 것입니다.다음은 시스템의 메모리가 사용되는 위치를 좁히는 방법과 데이터베이스가 다운된 경우 복구하는 방법입니다.
수집된 플러그인과 플러그인을 살펴봅니다.적용 가능한 것 중 일부는 프로세스 플러그인 및 메모리 플러그인일 수 있습니다.이를 통해 시스템의 메모리 사용량과 메모리 사용량의 대부분을 차지하는 프로세스를 확인할 수 있습니다.
Django를 실행하는 방법에 따라 특정 수의 요청만 처리한 다음 종료하도록 작업자 프로세스를 구성할 수 있습니다.이렇게 하면 응용 프로그램에서 메모리 누수가 발생하더라도 해당 요청 수를 초과하지 않습니다.예를 들어, Gunicorn을 사용하는 경우 --max-requests 옵션을 사용할 수 있습니다.500으로 설정하면 작업자가 500개의 요청을 처리한 후 작업자가 삭제됩니다.
위의 내용과 통계 수집을 결합하면 흥미로운 메모리 사용 추세를 볼 수 있습니다.
중단되는 데이터베이스에 대해서는 MySQL이 중단되면 자동으로 다시 시작되도록 프로세스 관리를 설정할 수 있습니다.최신 버전의 Ubuntu의 MySQL은 Upstart를 사용하여 이를 수행합니다.프로세스가 중단되면 Upstart가 즉시 프로세스를 다시 시작합니다.이 기본 제공 기능이 없는 다른 디스트리뷰터를 사용하는 경우 Supervisor를 확인하십시오.이것이 문제를 해결하지는 못하지만 적어도 그 영향을 완화시킬 것입니다.이는 해결책이 아니라 문제가 발생할 경우 응용프로그램을 계속 실행하는 방법으로 간주해야 합니다.
유사한 문제에 봉착했을 때, 사용자들이 DB 연결 설정 오류라는 추악한 메시지를 보게 되어 정말 실망했습니다.저는 정확한 문제를 해결하는 대신 이 레포가 저에게 매력적으로 (일시적으로) 작동한다는 것을 알게 되었습니다.그 후 친구에게 디버깅을 받았는데, 친구가 몇 가지 구성 변경 사항으로 서버를 미세 조정했습니다.하지만 10분마다 이 스크립트를 crontab에 추가하고 서버가 손상되었는지 확인한 다음 다시 시작합니다(서버에서 VNC Server를 실행할 때마다 서버가 손상됨).
저는 이 토론에서 답변 추가 사항을 발견하고 저를 위해 일했습니다: https://www.digitalocean.com/community/questions/mysql-server-keeps-stopping-unexpectedly?answer=26016
당신은 둘 다 해야 합니다.innodb_buffer_pool_size3,200만 달러 정도의 합리적인 금액으로.my.conf에/etc/mysql/my.cnf그리고 당신은 또한 수정이 필요할 수도 있습니다./etc/apache2/mods-enabled/mpm_prefork.confApache에 의해 시작되는 연결 수를 줄입니다.
<IfModule mpm_prefork_module>
StartServers 3
MinSpareServers 3
MaxSpareServers 5
MaxRequestWorkers 25
MaxConnectionsPerChild 0
</IfModule>
새 스왑 공간을 추가하여 사용 가능한 RAM을 늘리는 것도 도움이 될 수 있습니다.단계는 다음과 같습니다.
표시된 사용 가능한 공간보다 작은 크기의 /swap 파일을 생성해야 합니다.
df -h
예를 들어 df-h의 출력은 다음과 같습니다.
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.8G 1.2G 6.3G 16% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 492M 12K 492M 1% /dev
tmpfs 100M 336K 99M 1% /run
그래서 저는 2G를 사용하여 만들었습니다.
sudo fallocate -l 2G /swapfile
그런 다음 서비스를 시작합니다.
sudo /etc/init.d/mysql restart
이게 도움이 되길 바랍니다.행운을 빌어요.
언급URL : https://stackoverflow.com/questions/12114746/mysqld-service-stops-once-a-day-on-ec2-server
'bestsource' 카테고리의 다른 글
| 도커 합성 버전 3에서 depends_on의 조건 형식에 대한 대안은 무엇입니까? (0) | 2023.09.01 |
|---|---|
| [asyncError()] 호출이 비동기 상태 [MUST_DISPATCH]인 요청에 대해 유효하지 않습니다. (0) | 2023.09.01 |
| Spring Rest Template를 사용하여 Https Rest 서비스 액세스 (0) | 2023.09.01 |
| jQuery 빈칸() 대 제거() (0) | 2023.09.01 |
| CSS만을 사용하여 전체 요소의 너비가 아닌 텍스트의 너비에 대한 배경색을 설정하려면 어떻게 해야 합니까? (0) | 2023.09.01 |