Foros del Web » Administración de Sistemas » Cloud Computing »

php.ini consume muchisimos recursos

Estas en el tema de php.ini consume muchisimos recursos en el foro de Cloud Computing en Foros del Web. Desde hace unos meses tengo mi primer VPS no administrado con la siguiente maquina: CPU Dual Quad Core Xeon Centos 6 64 bits 2Gb Ram ...
  #1 (permalink)  
Antiguo 01/11/2012, 02:24
 
Fecha de Ingreso: noviembre-2012
Mensajes: 6
Antigüedad: 12 años, 1 mes
Puntos: 0
php.ini consume muchisimos recursos

Desde hace unos meses tengo mi primer VPS no administrado con la siguiente maquina:

CPU Dual Quad Core Xeon
Centos 6 64 bits
2Gb Ram + 2 Gb
1000Gb Transferencia

Tengo rodando 4 tiendas en magento y una web mas en joomla, desde hace unas semanas e notado muchas alertas del tipo
Resource counter_memory_share_used red alert on environment xxxx.vservers.es current value: 92 soft limit: 85 hard limit: 95 counter_memory_share_used
Resource counter_cpu_share_used yellow alert on environment xxxx.vservers.es current value: 82 soft limit: 85 hard limit: 95 counter_cpu_share_used

La memoria se me suele disparar al 85% y de normal, sin nadie en las tiendas, esta en 1.1 GB 55.4% (esto desde luego no es normal)

Tambien observo que la cpu se me dispara con los php.ini de 3 tiendas
1459 78.5 0.0 /usr/bin/php-cgi -c /var/www/vhosts/españa.com/etc/php.ini 0 19 75100 S 00:00:01 10003
1443 7.1 0.0 /usr/bin/php-cgi -c /var/www/vhosts/alemania.com/etc/php.ini 0 19 75960 S 00:00:04 10001
1449 4.4 0.0 /usr/bin/php-cgi -c /var/www/vhosts/italia.com/etc/php.ini 0 19 76400 S 00:00:01 10004

lunes tube 1500 visitas entre las tres a lo largo del dia por lo que creo que es mas de configuración que de capacidad.

e pasado el MsSQLTuner con estos resultados
>> MySQLTuner 1.2.0 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at mysqltuner.com
>> Run with '--help' for additional options and output filtering

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.61
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 3M (Tables: 280)
[--] Data in InnoDB tables: 477M (Tables: 2477)
[--] Data in MEMORY tables: 496K (Tables: 119)
[!!] Total fragmented tables: 2481

-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 16h 39m 53s (785K q [13.101 qps], 16K conn, TX: 1B, RX: 322M)
[--] Reads / Writes: 90% / 10%
[--] Total buffers: 27.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 442.2M (21% of installed RAM)
[OK] Slow queries: 0% (48/785K)
[OK] Highest usage of available connections: 5% (9/151)
[OK] Key buffer size / total MyISAM indexes: 8.0M/3.5M
[OK] Key buffer hit rate: 98.8% (650K cached / 7K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 165K sorts)
[!!] Joins performed without indexes: 1780
[OK] Temporary tables created on disk: 18% (38K on disk / 211K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 273K opened)
[OK] Open file limit used: 0% (0/1K)
[OK] Table locks acquired immediately: 100% (1M immediate / 1M locks)
[!!] InnoDB data size / buffer pool: 477.5M/2.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
Set thread_cache_size to 4 as a starting value
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (>= 8M)
join_buffer_size (> 128.0K, or always use indexes with joins)
thread_cache_size (start at 4)
table_cache (> 64)
innodb_buffer_pool_size (>= 477M)

mire el my.cnf y tenia solo esto
[mysqld]
local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

innodb_buffer_pool_size=2M
innodb_additional_mem_pool_size=500K
innodb_log_buffer_size=500K
innodb_thread_concurrency=2
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
innodb_buffer_pool_size=2M
innodb_additional_mem_pool_size=500K
innodb_log_buffer_size=500K
innodb_thread_concurrency=2

lo e modificado y ahora lo tengo asi:
[mysqld]
local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

innodb_buffer_pool_size=1G
innodb_additional_mem_pool_size=500K
innodb_log_buffer_size=500K
innodb_thread_concurrency=2
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
innodb_buffer_pool_size=2M
innodb_additional_mem_pool_size=500K
innodb_log_buffer_size=500K
innodb_thread_concurrency=2

### query-cache settings ###
query_cache_type=1
query_cache_size=64M
query_cache_limit=8M

# key_buffer_size is important for MyISAM tables.
key_buffer_size=16M
join_buffer_size=2M
thread_cache_size=4
table_cache=1024

log-slow-queries=/var/log/mysql.slow-queries.log

ahora estoy esperando las 24h para poder pasar de nuevo el MySQLTuner, pero... ¿creeis que puedo mejorar algo mas? no veo normal que consuma tanta memoria sin estar nadie visitando las tiendas. algo no esta bien, si necesitais mas datos o mas configuraciones os las ire poniendo.

Muchas Gracias de antemano
  #2 (permalink)  
Antiguo 01/11/2012, 10:01
 
Fecha de Ingreso: octubre-2010
Mensajes: 374
Antigüedad: 14 años, 2 meses
Puntos: 34
Respuesta: php.ini consume muchisimos recursos

Magento consume mucho el solo.......... :/

En cuanto a la RAM sin hacer nada, será todo cache y eso no es malo si no bueno, así funciona linux.

En cuanto a lo del PHP.ini, la verdad no es el PHP.ini el que consume si no PHP.

Lo que tu muestras:

1459 78.5 0.0 /usr/bin/php-cgi -c /var/www/vhosts/españa.com/etc/php.ini 0 19 75100 S 00:00:01 10003

Eso quiere decir que PHP se ejecuta como CGI y esta tomando la configuración del PHP.ini que esta en esa ruta /var/www/vhosts/españa.com/etc/php.ini

PHP.ini es solo el archivo de configuración.

Así que todo esto me hace suponer que tienes un problema con magento, tal vez un addon, plugin, theme etc que esta consumiendo PHP en exceso.. o sea un script muy pesado.

En todo caso puede ser normal, no he manejado mucho magento pero si he visto que consume más que otras tiendas.

Recomendaciones:

Intentar usar xcache, APC, Varnish o algún otro acelerador que use la RAM y no el disco duro para cachear, que si bien se consumirá más RAM la velocidad de carga mejorará y el consumo de recursos ( CPU ) disminuir.
__________________
Administrador de Servidores -> yo[arroba]skamasle[puntito]com
| Debian | Centos |
| Solución de Problemas | Seguridad | Instalaciones y Configuraciones | Soluciones Anti-DDOS
  #3 (permalink)  
Antiguo 01/11/2012, 10:17
Avatar de hyperwin  
Fecha de Ingreso: agosto-2010
Mensajes: 1.290
Antigüedad: 14 años, 4 meses
Puntos: 68
Respuesta: php.ini consume muchisimos recursos

Cita:
[!!] Query cache is disabled
Empieza por habilitarlo
__________________
Administrador de Servidores Windows
www.hyperwin.net
WebSitePanel - Helm Control - HostingController - DotNetPanel
Instalación - Configuración - Hardening - Solución de problemas
  #4 (permalink)  
Antiguo 01/11/2012, 12:47
 
Fecha de Ingreso: noviembre-2012
Mensajes: 6
Antigüedad: 12 años, 1 mes
Puntos: 0
Respuesta: php.ini consume muchisimos recursos

Cita:
Iniciado por skamasle Ver Mensaje
Magento consume mucho el solo.......... :/

En cuanto a la RAM sin hacer nada, será todo cache y eso no es malo si no bueno, así funciona linux.

En cuanto a lo del PHP.ini, la verdad no es el PHP.ini el que consume si no PHP.

Lo que tu muestras:

1459 78.5 0.0 /usr/bin/php-cgi -c /var/www/vhosts/españa.com/etc/php.ini 0 19 75100 S 00:00:01 10003

Eso quiere decir que PHP se ejecuta como CGI y esta tomando la configuración del PHP.ini que esta en esa ruta /var/www/vhosts/españa.com/etc/php.ini

PHP.ini es solo el archivo de configuración.

Así que todo esto me hace suponer que tienes un problema con magento, tal vez un addon, plugin, theme etc que esta consumiendo PHP en exceso.. o sea un script muy pesado.

En todo caso puede ser normal, no he manejado mucho magento pero si he visto que consume más que otras tiendas.

Recomendaciones:

Intentar usar xcache, APC, Varnish o algún otro acelerador que use la RAM y no el disco duro para cachear, que si bien se consumirá más RAM la velocidad de carga mejorará y el consumo de recursos ( CPU ) disminuir.
He instalado y configurado APC
apc.cfg
Código:
; Enable apc extension module
extension = apc.so

; Options for the APC module version >= 3.1.3
; See http://www.php.net/manual/en/apc.configuration.php

; This can be set to 0 to disable APC. 
apc.enabled=1
; The number of shared memory segments to allocate for the compiler cache. 
apc.shm_segments=1
; The size of each shared memory segment, with M/G suffix
apc.shm_size=512M
; A "hint" about the number of distinct source files that will be included or 
; requested on your web server. Set to zero or omit if you are not sure;
apc.num_files_hint=1024
; Just like num_files_hint, a "hint" about the number of distinct user cache
; variables to store.  Set to zero or omit if you are not sure;
apc.user_entries_hint=10000
; The number of seconds a cache entry is allowed to idle in a slot in case this
; cache entry slot is needed by another entry.
apc.ttl=7200
; use the SAPI request start time for TTL
apc.use_request_time=1
; The number of seconds a user cache entry is allowed to idle in a slot in case
; this cache entry slot is needed by another entry.
apc.user_ttl=7200
; The number of seconds that a cache entry may remain on the garbage-collection list. 
apc.gc_ttl=3600
; On by default, but can be set to off and used in conjunction with positive
; apc.filters so that files are only cached if matched by a positive filter.
apc.cache_by_default=1
; A comma-separated list of POSIX extended regular expressions.
apc.filters
; The mktemp-style file_mask to pass to the mmap module 
apc.mmap_file_mask=/tmp/apc.XXXXXX
; This file_update_protection setting puts a delay on caching brand new files.
apc.file_update_protection=2
; Setting this enables APC for the CLI version of PHP (Mostly for testing and debugging).
apc.enable_cli=1
; Prevents large files from being cached
apc.max_file_size=10M
; Whether to stat the main script file and the fullpath includes.
apc.stat=0
; Vertification with ctime will avoid problems caused by programs such as svn or rsync by making 
; sure inodes have not changed since the last stat. APC will normally only check mtime.
apc.stat_ctime=0
; Whether to canonicalize paths in stat=0 mode or fall back to stat behaviour
apc.canonicalize=0
; With write_lock enabled, only one process at a time will try to compile an 
; uncached script while the other processes will run uncached
apc.write_lock=1
; Logs any scripts that were automatically excluded from being cached due to early/late binding issues.
apc.report_autofilter=0
; RFC1867 File Upload Progress hook handler
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
; Optimize include_once and require_once calls and avoid the expensive system calls used.
apc.include_once_override=0
apc.lazy_classes=0
apc.lazy_functions=0
; Enables APC handling of signals, such as SIGSEGV, that write core files when signaled. 
; APC will attempt to unmap the shared memory segment in order to exclude it from the core file
apc.coredump_unmap=0
; Records a md5 hash of files. 
apc.file_md5=0
; not documented
apc.preload_path

¿algo que mejorar?
  #5 (permalink)  
Antiguo 01/11/2012, 12:50
 
Fecha de Ingreso: noviembre-2012
Mensajes: 6
Antigüedad: 12 años, 1 mes
Puntos: 0
Respuesta: php.ini consume muchisimos recursos

Cita:
Iniciado por hyperwin Ver Mensaje
Empieza por habilitarlo
En la configuración del my.cfg ya lo he añadido pero tengo que esperar 24h para que tenga efecto.

Código:
### query-cache settings ###
query_cache_type=1
query_cache_size=96M
query_cache_limit=8M
creo que con ponerlo en el my.cfg es suficiente, si es asi mañana lo vere funcionando. En caso contrario, que tenga que añadir algo mas, indicarmelo gracias
  #6 (permalink)  
Antiguo 01/11/2012, 16:57
 
Fecha de Ingreso: octubre-2010
Mensajes: 374
Antigüedad: 14 años, 2 meses
Puntos: 34
Respuesta: php.ini consume muchisimos recursos

Cita:
Iniciado por TITOTITA Ver Mensaje
En la configuración del my.cfg ya lo he añadido pero tengo que esperar 24h para que tenga efecto.

Código:
### query-cache settings ###
query_cache_type=1
query_cache_size=96M
query_cache_limit=8M
creo que con ponerlo en el my.cfg es suficiente, si es asi mañana lo vere funcionando. En caso contrario, que tenga que añadir algo mas, indicarmelo gracias
NO tienes que esperar 24 horas, con reiniciar mysql es suficiente, se recomienda esperar 24 / 48 horas para pasar el mysqltunner y similares por que se recompila más información, pero los valores se aplican de inmediato.

Lo del APC tu prueba configuraciones así encontrarás la que le haga mejor a tus página web y VPS siempre viendo el rendimiento y consumo etc.
__________________
Administrador de Servidores -> yo[arroba]skamasle[puntito]com
| Debian | Centos |
| Solución de Problemas | Seguridad | Instalaciones y Configuraciones | Soluciones Anti-DDOS
  #7 (permalink)  
Antiguo 01/11/2012, 19:23
 
Fecha de Ingreso: noviembre-2012
Mensajes: 6
Antigüedad: 12 años, 1 mes
Puntos: 0
Respuesta: php.ini consume muchisimos recursos

Cita:
Iniciado por skamasle Ver Mensaje
NO tienes que esperar 24 horas, con reiniciar mysql es suficiente, se recomienda esperar 24 / 48 horas para pasar el mysqltunner y similares por que se recompila más información, pero los valores se aplican de inmediato.
Tremendo fallo de novato, cuando puse el my.cnf no me di cuenta que estaba modificando todo despues de [mysqld_safe] por lo que no conseguia que funcionara nada de lo que estaba intentando mejorar. ahora ya e consultado en phpmyadmin y
Variable_name Value
query_cache_size 100663296

>> MySQLTuner 1.2.0 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.61
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 3M (Tables: 280)
[--] Data in InnoDB tables: 479M (Tables: 2477)
[--] Data in MEMORY tables: 0B (Tables: 119)
[!!] Total fragmented tables: 2482

-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 51s (406 q [7.961 qps], 25 conn, TX: 481K, RX: 139K)
[--] Reads / Writes: 89% / 11%
[--] Total buffers: 1.6G global + 12.2M per thread (400 max threads)
[!!] Maximum possible memory usage: 6.4G (319% of installed RAM)
[OK] Slow queries: 0% (0/406)
[OK] Highest usage of available connections: 1% (4/400)
[OK] Key buffer size / total MyISAM indexes: 512.0M/3.5M
[!!] Key buffer hit rate: 60.0% (10 cached / 4 reads)
[OK] Query cache efficiency: 43.5% (130 cached / 299 selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 50 sorts)
[!!] Temporary tables created on disk: 27% (20 on disk / 72 total)
[OK] Thread cache hit rate: 84% (4 created / 25 connections)
[OK] Table cache hit rate: 93% (107 open / 114 opened)
[OK] Open file limit used: 0% (22/2K)
[OK] Table locks acquired immediately: 100% (364 immediate / 364 locks)
[OK] InnoDB data size / buffer pool: 479.3M/1.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Reduce your overall MySQL memory footprint for system stability
Enable the slow query log to troubleshoot bad queries
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
tmp_table_size (> 128M)
max_heap_table_size (> 16M)

Despues de estos avisos:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
He bajado a 64m query_cache_size (lo tenia en 96m)
Variable_name Value
query_cache_size 67108864

por cierto el MySQLTuner me esta pidiendo que siga ampliando query_cache_limit voy por 24m ¿tengo que seguir subiendo?¿hasta cuanto?

Tengo 2Gb de memoria RAM y 2Gb en disco ¿que tamaño de cache pondrías?

Muchas gracias por tu paciencia
  #8 (permalink)  
Antiguo 02/11/2012, 07:52
 
Fecha de Ingreso: noviembre-2012
Mensajes: 6
Antigüedad: 12 años, 1 mes
Puntos: 0
Respuesta: php.ini consume muchisimos recursos

Tras muchas modificaciones al final consegui tener el MySQLTuner asi:

>> MySQLTuner 1.2.0 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.61-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 3M (Tables: 280)
[--] Data in InnoDB tables: 479M (Tables: 2477)
[--] Data in MEMORY tables: 0B (Tables: 119)
[!!] Total fragmented tables: 2482

-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 40m 27s (60K q [10.054 qps], 1K conn, TX: 89M, RX: 27M)
[--] Reads / Writes: 86% / 14%
[--] Total buffers: 555.0M global + 14.2M per thread (40 max threads)
[OK] Maximum possible memory usage: 1.1G (54% of installed RAM)
[OK] Slow queries: 0% (1/60K)
[OK] Highest usage of available connections: 10% (4/40)
[OK] Key buffer size / total MyISAM indexes: 6.0M/3.5M
[OK] Key buffer hit rate: 99.1% (7K cached / 63 reads)
[OK] Query cache efficiency: 84.1% (44K cached / 53K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2K sorts)
[OK] Temporary tables created on disk: 18% (669 on disk / 3K total)
[OK] Thread cache hit rate: 99% (4 created / 1K connections)
[OK] Table cache hit rate: 23% (2K open / 8K opened)
[OK] Open file limit used: 6% (284/4K)
[OK] Table locks acquired immediately: 100% (18K immediate / 18K locks)
[OK] InnoDB data size / buffer pool: 479.3M/500.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate

Tambien he bajado la memoria cache del ACP a 256mb ya que solo utilizaba 20mb de los 500 que le reserve.

Asi ha quedado el my.cnf

[mysqld]
local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

innodb_buffer_pool_size=500m
innodb_additional_mem_pool_size=500K
innodb_log_buffer_size=500K
innodb_thread_concurrency=2
### query-cache settings ###
query_cache_type=1
query_cache_size=16m
query_cache_limit=256m
log_slow_queries = 1
slow_query_log_file=/var/log/mysql.slow-queries.log

# key_buffer_size is important for MyISAM tables.
key_buffer_size=8M
key_buffer=6M
join_buffer_size=4M
thread_cache_size=8
table_cache=2048
max_allowed_packet=6M
sort_buffer_size=4m
read_buffer_size=4m
read_rnd_buffer_size=2m
myisam_sort_buffer_size=6m
tmp_table_size=256m
max_connections=40
wait_timeout=300
max_heap_table_size=32m

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
innodb_buffer_pool_size=2M
innodb_additional_mem_pool_size=500K
innodb_log_buffer_size=500K
innodb_thread_concurrency=2

Si algien ve algo que me pueda mejorar, lo agradeceria, por que aunque me dice que la memoria maxima usada seria del 1.1Gb sigo teniendo alertas por exceso de memoria. 1.8Gb sobre 2gb.
  #9 (permalink)  
Antiguo 03/11/2012, 19:08
 
Fecha de Ingreso: octubre-2010
Mensajes: 374
Antigüedad: 14 años, 2 meses
Puntos: 34
Respuesta: php.ini consume muchisimos recursos

Lo de 1.1GB es lo más que puede usar mysql.

OK] Maximum possible memory usage: 1.1G (54% of installed RAM)

Si quieres ver que usa la RAM tendrás que usar el comando TOP y ver que pasa, tal vez sea apache + PHP.

También free -m te dará algo de info, tal vez la mayoría de RAM sea cache que hay ahí acumulado y el sistema que te manda los avisos lo toma todo como RAM usada.

Si eso pega aquí la salida de ps aux con ese también puedes ver que consume más RAM.
__________________
Administrador de Servidores -> yo[arroba]skamasle[puntito]com
| Debian | Centos |
| Solución de Problemas | Seguridad | Instalaciones y Configuraciones | Soluciones Anti-DDOS

Etiquetas: recursos, vps
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 14:11.