Изпечатай

[abadon]

Здравейте,

Имам сървър със следните параметри: 4-ядрен Intel(R) Xeon(R) CPUE5504  @ 2.00GHz, SATA HDD 320 GB, 6GB RAM. На него съм инсталирал 64 bit-ово Ubuntu karmic, kernel 2.6.31-20-server, Nginx, Apache2-mpm-worker + php (fcgi), Mysql и Sendmail (default конфиг от aptitude).

Nginx слуша на 80-ти порт като ми сервира статичното съдържание, запитванията за динамичното се прехвърлят към Apache на 8080. Тази конфигурация е ползвам не толкова заради производителност, колкото за предпазване от един DoS експлойт за Apache който със 8-10 К интерет и без да остави никакви следи в логовете на Apache-то е в състояние да му изяде всичките worker-и и да доведе до отказ в обслужването. 
На apache-то имам пуснат mod_rewrite, mod_deflate и mod_expires.
Към php-то съм добавил eAccelerator и съм му пуснал gzip компресията 
Sendmail-а си е дефолт конфигурацията колкото да може php-тата да пращат мейли.

Проблема ми е следния всичката тази конфигурация отгоре я използвам само за да ми хоства сайта. Обаче забелязвам, че доста често когато имам около 100 човека онлайн изведнъж load-а на машината скача на 5 до 10 и като гледам с htop основната част от процесите виновни за това натоварване са на mysql-а. Друг път имам по 200 човека онлайн и load-а не е повече от 2. На какво може да се дължи този проблем? Как да го реша?
Ето това ми е my.cnf-то:

#                                 
# The MySQL database server configuration file.
#                                             
# You can copy this to one of:                 
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options. 
#                                             
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#                                                                   
# For explanations see                                               
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html     

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...                               
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]                                                                   
port            = 3306                                                     
socket          = /var/run/mysqld/mysqld.sock                             

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]                                                                 
socket          = /var/run/mysqld/mysqld.sock                                 
nice            = 0                                                           
open_files_limit = 16384                                                       

[mysqld]
#       
# * Basic Settings
#                 

#
# * IMPORTANT
#   If you make changes to these settings and your system uses apparmor, you may
#   also need to also adjust /etc/apparmor.d/usr.sbin.mysqld.                   
#                                                                               

user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306                       
basedir         = /usr                       
datadir         = /var/lib/mysql             
tmpdir          = /tmp                       
skip-external-locking                       
open_files_limit = 16384                     
#                                           
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.     
bind-address            = 127.0.0.1                             
#                                                               
# * Fine Tuning                                                 
#                                                               
key_buffer                               = 256M                 
join_buffer                              = 6M                   
max_allowed_packet               = 16M                           
thread_stack                     = 192K                         
thread_cache_size        = 128                                   
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched                                   
myisam-recover           = BACKUP                                   
max_connections          = 300                                       
table_cache              = 8192                                     
table_definition_cache   = 1024                                     
sort_buffer_size         = 2M                                       
read_buffer_size         = 4M                                       
read_rnd_buffer_size     = 4M                                       
thread_concurrency       = 8                                         
innodb_thread_concurrency =0                                         
max_heap_table_size              = 4M                               
#                                                                   
# * Query Cache Configuration                                       
#                                                                   
query_cache_limit                = 2M                               
query_cache_size         = 64M                                       
query_cache_min_res_unit = 1K                                       
#                                                                   
# * Logging and Replication                                         
#                                                                   
# Both location gets rotated by the cronjob.                         
# Be aware that this log type is a performance killer.               
# As of 5.1 you can enable the log at runtime!                       
#general_log_file        = /var/log/mysql/mysql.log                 
#general_log             = 1                                         
#                                                                   
# Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.
#                                                                             
# 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                               
#                                                                             
# * 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!             
#                                                                             
# * 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              = 64M

#
# * 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/

mysqltuner.pl ми казва следното нещо:

>>  MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net>
 >>  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.37-1ubuntu5.1-log         
[OK] Operating on 64-bit architecture                                         

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster               
[--] Data in MyISAM tables: 141M (Tables: 508)                               
[--] Data in InnoDB tables: 2M (Tables: 9)                                   
[!!] Total fragmented tables: 33                                             

-------- Performance Metrics -------------------------------------------------
[--] Up for: 8d 4h 41m 34s (247M q [350.009 qps], 5M conn, TX: 78B, RX: 30B) 
[--] Reads / Writes: 71% / 29%                                               
[--] Total buffers: 142.0M global + 16.2M per thread (300 max threads)       
[OK] Maximum possible memory usage: 4.9G (83% of installed RAM)               
[OK] Slow queries: 3% (9M/247M)                                               
[OK] Highest usage of available connections: 36% (110/300)
[OK] Key buffer size / total MyISAM indexes: 64.0M/76.6M
[OK] Key buffer hit rate: 100.0% (2B cached / 378K reads)
[OK] Query cache efficiency: 84.4% (183M cached / 216M selects)
[!!] Query cache prunes per day: 161645
[OK] Sorts requiring temporary tables: 0% (272 temp sorts / 6M sorts)
[!!] Joins performed without indexes: 146499
[OK] Temporary tables created on disk: 5% (343K on disk / 6M total)
[OK] Thread cache hit rate: 99% (112 created / 5M connections)
[!!] Table cache hit rate: 5% (804 open / 15K opened)
[OK] Open file limit used: 7% (1K/16K)
[OK] Table locks acquired immediately: 97% (62M immediate / 63M locks)
[OK] InnoDB data size / buffer pool: 2.0M/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Adjust your join queries to always utilize indexes
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (> 64M)
    join_buffer_size (> 6.0M, or always use indexes with joins)
    table_cache (> 8192)

tuning-primer.sh дава това:

       -- MYSQL PERFORMANCE TUNING PRIMER --
             - By: Matthew Montgomery -                                                                                                                                     

MySQL Version 5.1.37-1ubuntu5.1-log x86_64

Uptime = 8 days 4 hrs 42 min 27 sec
Avg. qps = 350                     
Total Questions = 247856109       
Threads Connected = 1             

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:                                                                                                                               
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html                                                                                                         
Visit http://www.mysql.com/products/enterprise/advisors.html                                                                                                               
for info about MySQL's Enterprise Monitoring and Advisory Service                                                                                                           
                                                                                                                                                                           
SLOW QUERIES                                                                                                                                                               
The slow query log is enabled.                                                                                                                                             
Current long_query_time = 2.000000 sec.                                                                                                                                     
You have 9358278 out of 247856260 that take longer than 2.000000 sec. to complete                                                                                           
Your long_query_time seems to be fine                                                                                                                                       

BINARY UPDATE LOG
The binary update log is NOT enabled.                                                                                                                                       
You will not be able to do point in time recovery                                                                                                                           
See http://dev.mysql.com/doc/refman/5.1/en/point-in-time-recovery.html                                                                                                     
                                                                                                                                                                           
WORKER THREADS                                                                                                                                                             
Current thread_cache_size = 128                                                                                                                                             
Current threads_cached = 111                                                                                                                                               
Current threads_per_sec = 0                                                                                                                                                 
Historic threads_per_sec = 0                                                                                                                                               
Your thread_cache_size is fine                                                                                                                                             

MAX CONNECTIONS
Current max_connections = 300                                                                                                                                               
Current threads_connected = 1                                                                                                                                               
Historic max_used_connections = 110                                                                                                                                         
The number of used connections is 36% of the configured maximum.                                                                                                           
Your max_connections variable seems to be fine.                                                                                                                             

INNODB STATUS
Current InnoDB index space = 688 K                                                                                                                                         
Current InnoDB data space = 2 M                                                                                                                                             
Current InnoDB buffer pool free = 40 %                                                                                                                                     
Current innodb_buffer_pool_size = 8 M                                                                                                                                       
Depending on how much space your innodb indexes take up it may be safe                                                                                                     
to increase this value to up to 2 / 3 of total system memory                                                                                                               

MEMORY USAGE
Max Memory Ever Allocated : 1.87 G                                                                                                                                         
Configured Max Per-thread Buffers : 4.74 G                                                                                                                                 
Configured Max Global Buffers : 138 M                                                                                                                                       
Configured Max Memory Limit : 4.87 G                                                                                                                                       
Physical Memory : 5.81 G                                                                                                                                                   
Max memory limit seem to be within acceptable norms                                                                                                                         

KEY BUFFER
Current MyISAM index space = 76 M                                                                                                                                           
Current key_buffer_size = 64 M                                                                                                                                             
Key cache miss rate is 1 : 6466                                                                                                                                             
Key buffer free ratio = 78 %                                                                                                                                               
Your key_buffer_size seems to be fine                                                                                                                                       

QUERY CACHE
Query cache is enabled                                                                                                                                                     
Current query_cache_size = 64 M                                                                                                                                             
Current query_cache_used = 4 M                                                                                                                                             
Current query_cache_limit = 2 M                                                                                                                                             
Current Query cache Memory fill ratio = 7.40 %                                                                                                                             
Current query_cache_min_res_unit = 1 K                                                                                                                                     
Your query_cache_size seems to be too high.                                                                                                                                 
Perhaps you can use these resources elsewhere                                                                                                                               
MySQL won't cache query results that are larger than query_cache_limit in size                                                                                             
                                                                                                                                                                           
SORT OPERATIONS                                                                                                                                                             
Current sort_buffer_size = 2 M                                                                                                                                             
Current read_rnd_buffer_size = 4 M                                                                                                                                         
Sort buffer seems to be fine                                                                                                                                               

JOINS
Current join_buffer_size = 6.00 M                                                                                                                                           
You have had 146505 queries where a join could not use an index properly                                                                                                   
join_buffer_size >= 4 M                                                                                                                                                     
This is not advised                                                                                                                                                         
You should enable "log-queries-not-using-indexes"                                                                                                                           
Then look for non indexed joins in the slow query log.                                                                                                                     

OPEN FILES LIMIT
Current open_files_limit = 16694 files                                                                                                                                     
The open_files_limit should typically be set to at least 2x-3x                                                                                                             
that of table_cache if you have heavy MyISAM usage.                                                                                                                         
Your open_files_limit value seems to be fine                                                                                                                               

TABLE CACHE
Current table_open_cache = 8192 tables                                                                                                                                     
Current table_definition_cache = 1024 tables                                                                                                                               
You have a total of 540 tables                                                                                                                                             
You have 821 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 4 M
Current tmp_table_size = 16 M
Of 6091199 temp tables, 5% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 4 M
Current table scan ratio = 3476 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 42
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.

Базата данни която ползвам е с размер от около 100 МВ и към момента има 2,622,906 записа.

От всичко казано до тук къде може да е проблема ми? Лоша конфигурация на mysql-а? Не ми стигат IO операциите към харда (тях не знам как да ги проверя) или пък нещо друго?

Линкове към скриптовете за тест:
mysqltuner.pl
tuning-primer.sh

Предварително благодаря!

[borovaka]

Аз не мога да помогна много по въпроса. Относно performance на harda намерих това http://www.linux.com/archive/feature/131063.
Ако е от диска пробвай да ги вкараш в RAID, предполагам ще се поосвежи малко.

[victim70]

Аз не виждам грешка някаква - но болен се гласи на легло, така че копай, явно има проблем.

Провери дали коректно затваря връзките към базата скриптовете. Друг вариянт е да се логва всеки път, отваряне на сесия е ресурсоемко.
Подобен проблем имах и го оправих като използвам вече отворена връзка, а ми и оставаха незатворени връзки, та и тях изчистих.

Двата случая с които съм се борил и открил (друг ги реши обаче):

Ефекта който наблюдавах. Работя на сървърчето с още 5 мои колеги - за 2 месеца нещата тръгваха на охлюв, рестарта ги оправяше за още един такъв период. Причина отваряне на връзки без затваряне  и присъединяване на нова сесия на всяко логване. Сесията изтича а връзката не се затваря

Случай 2 - 40-50 души работят на сървъра. Като влезнат всички нещата стават драматично бавно. Причината - за всяка зачвка изпълняваше login -> query -> logout. Решение persist connection.

едит:
Машината ти е супер
едит2:
Обаче 64 битовата версия вади по лошо бързодействие от 32 битовата - според някои ревюта

[abadon]

@borovaka благодаря за полезния линк. Резултатите просто са плачевни:

root@www:~# hdparm -T /dev/sda                                   

/dev/sda:
 Timing cached reads:   5220 MB in  2.00 seconds = 2610.75 MB/sec
root@www:~# hdparm -t /dev/sda                                 

/dev/sda:
 Timing buffered disk reads:    8 MB in  3.58 seconds =   2.24 MB/sec

root@www:~# fio random-read-test.fio   
random-read: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1
Starting 1 process                                                       
random-read: Laying out IO file(s) (1 file(s) / 128MB)                   

Jobs: 1 (f=1): [r] [100.0% done] [803K/0K /s] [196/0 iops] [eta 00m:00s]s]
random-read: (groupid=0, jobs=1): err= 0: pid=8623
  read : io=131072KB, bw=201030B/s, iops=49, runt=667650msec
    clat (msec): min=1, max=4575, avg=20.35, stdev=51.00
    bw (KB/s) : min=    2, max=  739, per=105.25%, avg=206.29, stdev=109.16
  cpu          : usr=0.03%, sys=25.26%, ctx=32436, majf=0, minf=86
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued r/w: total=32768/0, short=0/0

     lat (msec): 2=6.95%, 4=3.59%, 10=22.07%, 20=39.98%, 50=21.15%
     lat (msec): 100=5.09%, 250=0.89%, 500=0.16%, 750=0.05%, 1000=0.02%
     lat (msec): 2000=0.03%, >=2000=0.01%

Run status group 0 (all jobs):
   READ: io=131072KB, aggrb=196KB/s, minb=201KB/s, maxb=201KB/s, mint=667650msec, maxt=667650msec

Disk stats (read/write):
  dm-0: ios=32995/86279, merge=0/0, ticks=630180/45943090, in_queue=48741800, util=99.61%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
    sda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%

Не знам ти как смяташ но аз смятам че този хард на сървъра е боклук, като сравнявам резултатите си със лаптопа ми Acer Aspire 4810TZ Модела ми е със 4GB ram и под оправлението на същата OS като на сървъра, само kernela ми е 2.6.31-20-generic. Резултатите:

root@abadon:~# hdparm -T /dev/sda

/dev/sda:
 Timing cached reads:   2046 MB in  2.00 seconds = 1023.44 MB/sec
root@abadon:~# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  218 MB in  3.01 seconds =  72.41 MB/sec

root@abadon:~# fio random-read-test.fio   
random-read: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1
Starting 1 process
random-read: Laying out IO file(s) (1 file(s) / 128MB)
Jobs: 1 (f=1): [r] [99.7% done] [613K/0K /s] [149/0 iops] [eta 00m:01s]
random-read: (groupid=0, jobs=1): err= 0: pid=19811
  read : io=131072KB, bw=443623B/s, iops=108, runt=302549msec
    clat (usec): min=89, max=299969, avg=9223.10, stdev=4920.77
    bw (KB/s) : min=  189, max=  662, per=99.97%, avg=432.86, stdev=45.43
  cpu          : usr=0.13%, sys=0.34%, ctx=32770, majf=0, minf=46
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued r/w: total=32768/0, short=0/0
     lat (usec): 100=0.02%, 250=1.33%, 500=0.92%, 750=0.06%, 1000=0.02%
     lat (msec): 2=0.09%, 4=5.83%, 10=50.55%, 20=39.11%, 50=2.05%
     lat (msec): 100=0.02%, 250=0.01%, 500=0.01%

Run status group 0 (all jobs):
   READ: io=131072KB, aggrb=433KB/s, minb=443KB/s, maxb=443KB/s, mint=302549msec, maxt=302549msec

Disk stats (read/write):
  sda: ios=32702/656, merge=0/2928, ticks=288170/11010, in_queue=299150, util=95.37%

Дали от вида на файловата система и начина на монтиране може да се получава такава голяма разлика? На лаптопа ми файловата система е reiserfs без LVM монтирана натака:

# / was on /dev/sda5 during installation
UUID=291ed64b-25de-448c-9278-69a2e504d0cb /               reiserfs notail          0       1

А на сървъра е reiserfs със LVM монтирана така:

/dev/mapper/storage-root /               reiserfs noatime,notail,defaults        0       1

@victim70 Не съм разглеждал твоите съвети подробно все още, но не ползвам пернаментни връзки към mysql-а. Ще ги разгледам като отстраня горния проблем.

[tolostoi]

Прекалено бавен изглежда харда (не зная дали hdparm е нещо на което може да се разчита и дали по време на теста диска не е много натоварен с друго), прегледай кернел лога дали не плюе грешки, не ти е от лвм-то. Ето при мен изход и то от обединени 2 райд1 масива  в един Volume group

Код:

hdparm -t /dev/mapper/first-samba

/dev/mapper/first-samba:
 Timing buffered disk reads:  200 MB in  3.03 seconds =  66.08 MB/sec

Мисля, че ти имаше и друга тема с мъка по mysql-a, май най-добре ще е да погледнете с някои който разбира какви куерита прави и да се оптимизира ако е възможно.

[borovaka]

Защо не пробваш с RAID масив. Би трябвало да се подобрят нещата с бързодействието.
А относно lvm не вярвам да ти създава проблем поне до сега аз съм нямал такъв, само ми е улеснявало живота

[abadon]

@tolostoi Да преди бях пускал също тема за бавен mysql, но тогава още не бях намерил двата скрипта за оптимизация, към които съм дал линкове в първия си пост. И по важното тогава mysql-а беше на виртуална машина със 256МВ ram, харда ми беше 8GB и нямах сведения виртуалното CPU колко ползва от реалното на хипервайзора.  Иначе и на мен ми се вижда страшно бавен харда, тъй като и на теста с fio който ми се вижда по-достоверен резултата е лош.  Ето hdparm пуснат на виртуална машина с LVM хоствнана на vmware ESXi 3.5 с локален сторидж върху RAID-5 масив.

hdparm -t /dev/mapper/storage

/dev/mapper/storage:
 Timing buffered disk reads:  1274 MB in  3.02 seconds = 422.40 MB/sec

Гледам hdparm-а го пускаш срещу LVM-а не към харда защото имам сериозна разлика между двете, което не знам дали е нормално?

oot@www:~# hdparm -t /dev/mapper/storage-root

/dev/mapper/storage-root:
 Timing buffered disk reads:  138 MB in  3.31 seconds =  41.74 MB/sec
root@www:~# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:    8 MB in  3.14 seconds =   2.54 MB/sec

В LVM-а имам само този хард.

@borovaka май към RAID отива работата, макар че преди да стигна до там искам да извлека всичко, което мога от наличния хардуер. Тъй като за райда си трябват и още не малко пари за хардуер, които към момента нямам.

Днес докато си мислех как да разреша проблема стигнах до това решение дали може да се реализира или е само моя фантазия? Тъй като базата ми данни е около 100 МВ и нараства със 2-3 МВ на ден има ли вариант да накарам mysql-а да не пише по харда? Смисъл сега да load-не в RAM-а тези 100 МВ база и да си я държи само в RAM-а като примерно нощем когато нямам натоварване да правя по един dump на харда. С цел ако огасне тока да не загубя цялата информацията а да загубя само не запазеното на харда. Дали може да се направи такава конфигурация?

[nemanema]

root@www:~# hdparm -T /dev/sda                                   

/dev/sda:
 Timing cached reads:   5220 MB in  2.00 seconds = 2610.75 MB/sec
root@www:~# hdparm -t /dev/sda                                 

/dev/sda:
 Timing buffered disk reads:    8 MB in  3.58 seconds =   2.24 MB/sec

Здрасти, не че му разбирам на Ubuntu, но ако цитираните показатели на диска са точни, мога да кажа само едно много лоша организация на ОС и файлова структура. Относно проблема с лоудинга на машината, очевидно е страданието за дисков тракт. Или да се смени дисковият масив с адекватен (примерно 4 х Seagate 15k.7 RAID 10 или 2 x Intel X25-SLC RAID 1 за базата данни) или да се направи масив от много (поне малки по обем но "пъргави" SATA2 дискове в RAID 10 в малък размер на парчетата за слепване  и за разпределяне (е няма добро българско обяснение с малко думи "stripe size").
Успех !

П.П. като си се сдобивал с машината защо не си предвидил натоварването на дисковият тракт ?

[borovaka]

abadon май има начин да се осъществи това. Аз си нямам идея от mysql но това ми изглежда като решение на това което си замислил:
http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html
Дано ти помогне.

[abscent]

И аз да взема да взема участие в тази тема, макар и малко позакъсняло
Като цяло натоварването на диска (т.е. I/O-операциите) могат много удобно да се видят с инструмента iotop - показва в реално време (през определен интервал все пак) кой процес с каква скорост в коя директория пише/чете. Би трябвало да го има в хранилищата на debian - в gentoo се компилира с emerge iotop, няма някакви големи зависимости от други пакети.
По отношение на въпроса как да се монтира директорията, в която пише mysql-демона - идеята е да може да се монтира директория като tmpfs-файлова система (man mount - низ tmpfs), и периодично през cron да се синхронизира съдържанието на директорията с базата данни, която си 'почива' на диска...
дано да стане ясно какво имам предвид, ако има нужда, мога да поясня 

[abadon]

@borovaka Благодаря за линка ще го разгледам и ще пиша какъв е бил резултата.

@abscent благодаря за полезния инструмент iotop! Относно идеята ти за mysql-а ако разбирам правилно създавам си една tmpfs файлова система която се разполага в рама, след което я монтирам примерно в /tmpfs и казвам на mysql-а че работната му директория е примерно /tmpfs/mysql след което през cron-а копирам всички файлове от /tmpfs/mysql примерно в /var/mysql Това ли е идята? Така няма ли някой файлове от /tmpfs/mysql да не могат да се копират защото се използват?

[abadon]

Полуфинално нещата ги направих така:

1. Създадох върху автоматично монтираната ми от Ubuntu-то tmpfs, като /dev/shm следните две директории:

# mkdir /dev/shm/mysql
# mkdir /dev/shm/mysql/temp

Ако ползвате дистрибуция която не монтира автоматично tmpfs файлова система. Може да си монтирате такава по следния начин:

# mkdir -p /mnt/tmp

# mount -t tmpfs -o size=256m tmpfs /mnt/tmp

В /etc/fstab се описва по този начин:

tmpfs /mnt/tmp tmpfs size=256M,mode=0777 0 0

2. Новосъздадените директории ги направих собственост на mysql. Посредством тези команди:

# chown mysql:mysql /dev/shm/mysql/
# chown mysql:mysql /dev/shm/mysql/temp

3. Редактирах my.cnf-то, като промених тези два параметъра datadir и tmpdir. В моят случай така:

datadir         = /dev/shm/mysql
tmpdir          = /dev/shm/mysql/temp

4. За да нямам проблеми с apparmor-а във файла  /etc/apparmor.d/usr.sbin.mysqld добавих следните редове:

# Give access of mysql to use /dev/shm
# Start
  /dev/shm/mysql r,
  /dev/shm/mysql/** rwk,
# End

Ако не се ползва apparmor тази стъпка не е нужна. Ако някой ползва SELinux трябва да извърши еквивалента на тази конфигурация само че за SELinux.
5. Спрях mysql сървъра:

/etc/init.d/mysql stop

6. Копирах всички файлове на mysql-а от харда във рама:

cp -ar /var/lib/mysql/* /dev/shm/mysql/

7. Стартирах отново mysql сървъра:

/etc/init.d/mysql start

Воала базата ми данни тръгна доста по-бързо! 

От тук насам вече почват тънките моменти. Трябва да се има предвид, че при рестарт на машината цялата информация от /dev/shm ще изчезне! Затова периодично през cron-а в ненатоварените моменти пускам този "скрипт" mysqlbackup-shm.sh :

# /bin/sh
# Backup All Mysql files from RAM to hard drive
cp -ar /dev/shm/mysql/* /var/backups/mysql/dev/shm/ &

който ми синхронизира RAM-а със хардиска.
Плюс са по голяма сигурност си пускам и всяка нощ Automysqlbackup.sh

И за да съм абсолютно сигурен, че нищо няма да се намаже, преди рестарт на машината бих препоръчал извършването на стъпка 5 и пускането на mysqlbackup-shm.sh


След като машината се стартира отново за да не се повтарят горните стъпки може да се пусне mysql-on-tmpfs.sh:

# /bin/bash
# Mysql to tmpfs
echo After script finish you need to start mysql server
mkdir /dev/shm/mysql &&
mkdir /dev/shm/mysql/temp &&
chown mysql:mysql /dev/shm/mysql/ &&
chown mysql:mysql /dev/shm/mysql/temp &&
/etc/init.d/mysql stop &&
cp -ar /var/backups/mysql/dev/shm/* /dev/shm/mysql/

Дано съм бил полезен и на някой друг който е решил да пусне mysql върху tmpfs


Молбата ми е ако има някой по-добър с bash-а и със init скриптовете да каже как може да се направи автоматично при shutdown/reboot на машината де се изпълнява стъпка 5 и mysqlbackup-shm.sh. Респективно при стартиране да се изпълнява mysql-on-tmpfs.sh след което да се стартира автоматично mysql сървъра.

[Naka]

Без да съм чел всичко подробно в поста, искам да споделя моят опит.

Виждал съм такова разваляне на хард. Скоростта на трансфер пада от 60-70MB/Sec до 2-3 Мб/Sec. Като всичко друго с харда е наред: Няма лоши сектори, няма развалени данни, няма проблеми.

Приложенията работят без грешка, само дето много се кумят като  се обръщат към диска.

проблема се виждаше само чрез hdparm -t /dev/xxxxx, A диска беше Maxtor 20Gb.
Пусни резултата от smartctl --all /dev/sda

Пускаш едно LiveCD тестваш с hdparm (или sdparm?) и ако даде 2-3 MB/sec (под 10) можеш да хвърлиш харда. добре е да закачиш и друг диск на този кабел да видиш дали не е нещо от чипсета. или пък този диск го тествай за скорост на друг компютър.

Здрасти, не че му разбирам на Ubuntu, но ако цитираните показатели на диска са точни, мога да кажа само едно много лоша организация на ОС и файлова структура.

Показанията на hdparm -t върху физически диск, не зависят от файловата структура.