Jump to content
Sign in to follow this  
furiaceka

Server down ogni giorno

Recommended Posts

Sembra proprio che il server esaurisca la ram e inizi a swappare (picco di iowait nel grafico della CPU).

Bisognerebbe controllare bene la config di MySQL, magari ci sono valori assurdi che fanno si che non appena alcune richieste si accodano inizia a "mangiare" un sacco di RAM.

Share this post


Link to post
Share on other sites

Io prima di prendere un upgrade volevo capire se effetivamente era la ram a non bastare e soprattutto se è possibile che un forum phpbb con 10000 iscritti e massimo 100 users in contemporanea necessiti di più di 1gb di ram.

Vi allego i grafici aggiornati con un pò più dati e il mio attuale my.cnf.

[mysqld]
local-infile=0
skip-innodb
log-slow-queries=/var/log/mysql-slow-queries.log
long_query_time = 1
log-queries-not-using-indexes
#
# * Fine Tuning
#
query_cache_min_res_unit = 4K 
key_buffer              = 80M
max_allowed_packet      = 16M
thread_stack            = 128K
thread_cache_size       = 64

# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover          = BACKUP
#max_connections        = 100
table_cache            = 512
thread_concurrency     = 8


#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 32M


#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log            = /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
#log_slow_queries       = /var/log/mysql/mysql-slow.log
long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id              = 1
#log_bin                        = /var/log/mysql/mysql-bin.log
#expire_logs_days        = 10
#max_binlog_size         = 100M
#binlog_do_db           = include_database_name
#binlog_ignore_db       = include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer              = 16M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1


#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

grafici.zip

Share this post


Link to post
Share on other sites
Io prima di prendere un upgrade volevo capire se effetivamente era la ram a non bastare e soprattutto se è possibile che un forum phpbb con 10000 iscritti e massimo 100 users in contemporanea necessiti di più di 1gb di ram.

Vi allego i grafici aggiornati con un pò più dati e il mio attuale my.cnf.

 

Sicuramente c'è da ottimizzare la config di MySQL, scarica e lancia questo script: http://www.hostingtalk.it/forum/gestione-server-windows-linux-co/12302-script-php-per-lottimizzazione-di-mysql.html

 

Comunque per tagliare di netto l'utilizzo di RAM potresti passare ad nginx + php-fpm lasciando Apache.

Share this post


Link to post
Share on other sites
Sicuramente c'è da ottimizzare la config di MySQL, scarica e lancia questo script: http://www.hostingtalk.it/forum/gestione-server-windows-linux-co/12302-script-php-per-lottimizzazione-di-mysql.html

 

Comunque per tagliare di netto l'utilizzo di RAM potresti passare ad nginx + php-fpm lasciando Apache.

 

Già scaricato quello script ed ecco l'output:

Connections per second: 1.8348

Kilobytes received per second: 16.0284

Kilobytes sent per second: 42.6983

Queries per second: 204.1268

Percentage of slow queries: 0.0078

Opened vs. Open tables: (table_cache) 1.0748 MySQL uses the table cache to keep tables open when database connections aren't using them. This makes future accesses to those tables faster.

Table cache usage(unico valore in arancio):(table_cache) 0.2871 Your table cache is more than half empty. Having a table cache bigger than needed uses memory that is likely better used elsewhere. Make sure MySQL has been running for some days before adjusting this downwards.

MyISAM key buffer read hit rate:(key_buffer_size) 1371.7961 The MyISAM key buffer holds the indexes for MyISAM tables. The indexes help MySQL find the actual data in the table quickly. If the indexes aren't in memory, MySQL must load them from disk first, causing severe performance degredation.

Thread cache hit rate:(thread_cache_size) 4269.8621 Each connection to MySQL requires a thread. Threads can be re-used between connections if there is room in the cache to store the thread when not in use.

Thread cache usage: (thread_cache_size) 0.4063

Temporary table disk usage:(tmp_table_size, max_heap_table_size) 0.0543 If a temporary table in memory exceeds the specified limits, it is pushed to disk. This can slow complex queries down.

Query cache enabled:(query_cache_type) 1 The query cache is used avoid executing the same query again. If the tables the query accesses haven't changed, MySQL can return the cached results for the query.

Query cache miss rate:(query_cache_size, query_cache_limit) 0.0472

Query cache prune rate: (query_cache_size) 0

 

Questo è invece l'output di MySQLTuner

>> MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net>

 

 

-------- General Statistics --------------------------------------------------

[--] Skipped version check for MySQLTuner script

[!!] Your MySQL version 4.1.10-standard-log is EOL software! Upgrade soon!

[OK] Operating on 32-bit architecture with less than 2GB RAM

 

-------- Storage Engine Statistics -------------------------------------------

[--] Status: +Archive -BDB -Federated -InnoDB -ISAM -NDBCluster

[--] Data in MyISAM tables: 218M (Tables: 68)

[!!] Total fragmented tables: 13

 

-------- Performance Metrics -------------------------------------------------

[--] Up for: 18h 54m 5s (13M q [204.578 qps], 125K conn, TX: 3B, RX: 1B)

[--] Reads / Writes: 71% / 29%

[--] Total buffers: 138.0M global + 2.6M per thread (100 max threads)

[OK] Maximum possible memory usage: 400.5M (39% of installed RAM)

[OK] Slow queries: 0% (108K/13M)

[OK] Highest usage of available connections: 28% (29/100)

[OK] Key buffer size / total MyISAM indexes: 80.0M/81.0M

[OK] Key buffer hit rate: 99.9% (38M cached / 28K reads)

[OK] Query cache efficiency: 95.3% (12M cached / 13M selects)

[OK] Query cache prunes per day: 0

[OK] Sorts requiring temporary tables: 0% (43 temp sorts / 30K sorts)

[OK] Temporary tables created on disk: 5% (1K on disk / 22K total)

[OK] Thread cache hit rate: 99% (29 created / 125K connections)

[OK] Table cache hit rate: 93% (147 open / 158 opened)

[OK] Open file limit used: 19% (219/1K)

[OK] Table locks acquired immediately: 99% (1M immediate / 1M locks)

 

-------- Recommendations -----------------------------------------------------

General recommendations:

Run OPTIMIZE TABLE to defragment tables for better performance

MySQL started within last 24 hours - recommendations may be inaccurate

 

Faccio un optimize ogni giorno alle 04.00 am messo in cron!

Share this post


Link to post
Share on other sites

Semplicemente non potevi fare lo script che ti dicevo? secondo me a quest'ora avremmo già finito :)

 

Ad ogni modo è un problema di risorse insufficienti, e poi potrebbe anche trattarsi di qualche applicativo che fa molte query non chiudendole a livello di php.

 

Potresti semplicemente fare un apt-get install mytop e dopo di che mytop -u root -p PASSWORD

 

Dopo pigia il tasto s e premi 1.

 

Così ogni secondo vedi quante query fai.....

 

Se la schermata si riempie....... beh ecco il problema!

Share this post


Link to post
Share on other sites
Stasera c'è stato un altro blocco. Vi allego i grafici, sono riuscito a scorgere l'errore too many connection di mysql può essere quello il problema.

 

Swappi fino a quando il server muore, il picco di processi viene causato da apache, che spawna nuovi child per tenere in attesa le richieste ed accettarne di nuove; tutto questo fino a quando non raggiunge il valore maxclients (nei log dovresti avere un warning che hai raggiunto il maxclients).

 

Se il log delle slow query è vuoto, e non è neanche un problema di uno script PHP che si impalla, allora o diminuisci il numero di maxclient o aumenti le risorse hardware o provi a sostituire apache con nginx.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×