servidores - instalar wordpress amazon linux
El servicio mysqld se detiene una vez al día en el servidor ec2 (5)
Usa el 50% de la RAM disponible para probar:
Puede disminuir el innodb_buffer_pool_size muy bajo para ver si ayuda:
#/etc/my.cnf
innodb_buffer_pool_size = 1M
Una regla de oro es establecer innodb_buffer_pool_size al 50% de la memoria RAM disponible para las pruebas de memoria baja. Esto significa que inicia el servidor y todo excepto MySQL InnoDB. Vea la cantidad de RAM que tiene. Luego usa el 50% de eso para InnoDB.
Para probar muchas configuraciones de memoria baja a la vez:
Un culpable más probable es cualquier otra cosa que esté en ese servidor, como un servidor web.
¿Apache?
¿Estás usando Apache y / u otro servidor web? Si es así, intenta disminuir su uso de RAM. Por ejemplo, en Apache conf, considere una configuración de RAM baja como esta:
StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 5
Y limite las solicitudes de esta manera:
MaxRequestsPerChild 300
Luego reinicia Apache.
mod_wsgi:
Si está utilizando Apache con mod_python, cambie a Apache con mod_wsgi.
Pympler:
Si aún está sucediendo, posiblemente tu Django esté creciendo constantemente. Pruebe el perfil de memoria Django con Pympler:
SAR:
Su informe de fallas de una vez por día y luego de una vez por semana puede indicar algún tipo de trabajo cron que se ejecute diariamente o semanalmente. Por ejemplo, tal vez haya un proceso por lotes que requiera mucha RAM, un volcado de base de datos, etc.
Para rastrear el uso de RAM y buscar picos de RAM una hora antes de que fallezca MySQL, eche un vistazo a SAR, que es una gran herramienta: http://www.thegeekstuff.com/2011/03/sar-examples/
Detalles del entorno:
Server: Amazon ec2 Linux
Web Server: Apache
Web Framework: Django with mod_wsgi
A continuación he encontrado en el archivo 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
Parece que la memoria del sistema no es suficiente para asignar memoria al grupo de búferes. El mismo error ocurre cuando estaba usando la Amazon ec2 micro instance , así que me mudé a la small instance . Funciona bien durante algunos días, pero ahora se está rompiendo una vez al día nuevamente. ¿Hay una solución permanente para eso? Puedo pasar a una instancia mediana pero el problema es si eso se solucionará o no. ¿Debo disminuir el innodb_buffer_pool_size , cuál es el tamaño preferido?
El resultado de cat /proc/meminfo es el siguiente (puede ser que ayude):
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
Versión del sistema operativo (uname -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
Comprobé el comando ps aux si el servidor tiene solo 15 MB de memoria y estos son el proceso httpd se está ejecutando en ese momento:
El resultado de free -m
total used free shared buffers cached
Mem: 1657 1628 29 0 3 19
-/+ buffers/cache: 1605 51
Swap: 895 875 20
El resultado de 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
¿Alguien puede tener una idea de por qué hay tanto proceso de httpd?
Aumentar la memoria RAM disponible añadiendo un nuevo espacio de intercambio también puede ser útil. Los pasos están here
Asegúrese de crear / intercambiar archivos del tamaño más pequeño que el espacio disponible mostrado por
df -h
Por ejemplo, para mí, la salida de df-h fue:
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
Así que creé usando 2 G
sudo fallocate -l 2G /swapfile
Y luego solo comienza el servicio
sudo /etc/init.d/mysql restart
Espero que esto ayude. Todo lo mejor.
Como otros han mencionado, el problema parece ser que su sistema tiene poca memoria RAM y MySQL está explotando debido a eso. A continuación, se explica cómo limitar el uso de la memoria de su sistema y cómo realizar la recuperación desde la base de datos.
Eche un vistazo a collectd y sus complementos. Algunos de los aplicables pueden ser el plugin de procesos y el plugin de memoria . Con ellos puede ver el uso de memoria de sus sistemas y qué procesos están ocupando la mayor parte.
Según cómo esté ejecutando Django, puede configurar los procesos de trabajo para que solo procesen una determinada cantidad de solicitudes y luego finalicen. De esa forma, si hay algún tipo de pérdida de memoria en su aplicación, no persistirá más allá de esa cantidad de solicitudes. Por ejemplo, si usa Gunicorn , puede usar la opción --max-requests . Al establecerlo en 500, se eliminará al trabajador después de que haya procesado 500 solicitudes.
Lo anterior combinado con la colección de estadísticas le mostrará algunas tendencias de uso de memoria interesantes.
En cuanto a la base de datos que baja, puede configurar la supervisión del proceso para que si MySQL muere, se relanzará automáticamente. MySQL en la última versión de Ubuntu usa Upstart para hacer justamente eso. Si el proceso muere, Upstart lo traerá de vuelta inmediatamente. Si está utilizando otra distribución que no tiene esta función incorporada, eche un vistazo a Supervisor . Si bien esto no soluciona el problema, al menos mitigará sus efectos. Esto no debe verse como la solución, sino como una forma de mantener la aplicación en funcionamiento en caso de que algo salga mal.
Tienes que disminuir tu innodb_buffer_pool_size = <60-80% de tu memoria principal)
Solución para Innodb Error:
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
Fuente: http://www.onaxer.com/tag/error-plugin-innodb-init-function-returned-error/
Una vez que me quedé atrapado en problemas similares, me sentí realmente frustrado de que mis usuarios vieran este desagradable mensaje de que el error al establecer una conexión de base de datos . En lugar de resolver los problemas exactos, encontré que este repositorio funcionaba como un amuleto para mí (temporalmente). Después de eso, mi amigo me depuró y él sintonizó mi servidor con algunos cambios de configuración. Pero todavía agregué este script a mi crontab cada 10 minutos y luego verifico si el servidor se colgó (lo que para mi caso se colgó eventualmente cada vez que ejecuto VNCServer en mi servidor) y luego lo reinicié