Linux Centos MySQL PHP InnoDB上的內存管理

Question

該服務器是否有足夠的內存（如果有），怎么知道？ 您會建議什么變化？

我希望對我應該如何管理虛擬機LAMP堆棧的內存有一些了解，或者更具體地說，如何配置以最大化可用內存。 我不是在尋找諸如“您需要更多內存”或“停止使用innodb”或“您需要切換到fastcgi來提供PHP”之類的答案。 在不更改任何堆棧的情況下，我正在尋找有關如何確定服務器是否具有足夠內存以及如何調整其性能的答案。 一個很好的經驗法則就好，您的交換大小應該等於您的系統內存（這只是一個例子，可以幫助我，我不知道這是不是真的）。

有關正在發生的事情的更多背景信息，我有類似的服務器開始崩潰，然后我的服務器運行相同的堆棧，並且Web應用程序的內存增加了，從而解決了該問題。 現在，我知道那是因為它們有更多的內存並且可以“處理”負載，但是我感覺盲目地增加服務器大小而又不了解底層機制可能不是一個好方法。 另外，從直覺上來說，我認為512MB的Web服務器應該可以處理幾乎所有內容，而且我知道我以前使用的服務器要少得多。

130201 21:04:27  mysqld restarted
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130201 21:04:27  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
130201 21:04:28  InnoDB: Started; log sequence number 0 4945108
130201 21:04:28 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.77'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

Number of processes running now: 0
130201 21:08:48  mysqld restarted
InnoDB: Error: pthread_create returned 11
130201 21:08:57  mysqld ended

130201 21:26:19  mysqld started
130201 21:26:35  InnoDB: Error: cannot allocate 8404992 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 8154720 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
130201 21:26:58  mysqld ended

我現在知道以上內容是由於崩潰導致的，可能是因為MySQL沒有足夠的內存，或者是因為InnoDB占用了太多內存，並且沒有足夠的OS來維持其功能。 以下是活動不足時我的一台典型服務器的頂部。 我不知道如何解釋這一點。 例如，100mb免費可以嗎？ 為什么會有這么多的Apache線程使用300m以上的內存，並且這種線程可持續性如何？ 我的InnoDB緩沖池應該是多少？ 任何幫助或指導將不勝感激！

top - 01:56:34 up 3 days,  4:05,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:  74 total,   3 running,  71 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    524288k total,   424172k used,   100116k free,    11680k buffers
Swap:   499992k total,   102684k used,   397308k free,    56552k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                   
26702 apache    15   0  321m  46m 6068 S  0.0  9.1   0:59.08 httpd                                                      
26701 apache    15   0  316m  41m 6312 S  0.0  8.1   0:32.04 httpd                                                      
26705 apache    15   0  313m  30m 6292 S  0.0  5.9   0:31.81 httpd                                                      
26707 apache    15   0  311m  37m 6372 S  0.0  7.3   0:27.49 httpd                                                      
26704 apache    15   0  311m  23m 5820 S  0.0  4.6   0:28.30 httpd                                                      
20799 apache    15   0  310m  35m 6488 S  0.0  7.0   0:27.43 httpd                                                      
26703 apache    15   0  307m  32m 6240 S  0.0  6.4   0:27.78 httpd                                                      
11123 apache    15   0  307m  30m 5984 S  0.0  5.9   0:10.26 httpd                                                      
26410 apache    15   0  297m  21m 5704 S  0.0  4.3   0:17.26 httpd                                                      
 7871 apache    15   0  296m  23m 5616 S  0.0  4.6   0:09.18 httpd                                                      
26708 apache    15   0  296m  20m 5616 S  0.0  4.1   0:25.38 httpd                                                      
26706 apache    15   0  295m  22m 5636 S  0.0  4.4   0:25.78 httpd                                                      
 1332 root      18   0  279m 5452 3632 R  0.0  1.0   0:00.23 httpd                                                      
 1305 mysql     15   0  195m  10m 3836 S  0.0  2.0   0:26.57 mysqld                                                     
10551 root      17   0 99.7m 1196  900 S  0.0  0.2   0:00.00 crond                                                      
10595 root      17   0 99.7m 1196  900 S  0.0  0.2   0:00.00 crond                                                      
10651 root      17   0 99.7m 1196  900 S  0.0  0.2   0:00.00 crond                                                      
10695 root      17   0 99.7m 1196  900 S  0.0  0.2   0:00.00 crond                                                      
10481 root      16   0 91068 3284 2564 S  0.0  0.6   0:00.00 sshd                                                       
10485 assistrx  15   0 91068 1744  976 S  0.0  0.3   0:00.00 sshd                                                       
 5739 root      15   0 90144 3268 2556 S  0.0  0.6   0:00.00 sshd                                                       
 5741 assistrx  15   0 90144 1720  980 S  0.0  0.3   0:00.00 sshd                                                       
 9687 root      15   0 90144 3388 2652 R  0.0  0.6   0:00.01 sshd                                                       
 1340 root      15   0 74848  700  592 S  0.0  0.1   0:00.04 crond                                                      
 9690 root      15   0 66104 1600 1180 S  0.0  0.3   0:00.00 bash                                                       
 1132 root      18   0 65968 1176 1032 S  0.0  0.2   0:01.48 xe-daemon                                                                                       

Answer 1

MySQL DB調整可能令人生畏，但這是可行的。 從RolandoMySQLDBA中查看此答案 。 他關於如何測量InnoDB緩沖池的建議非常完美，我建議您在innodb_file_per_table上進行嘗試，因為在您不得不處理一個龐大的InnoDB崩潰文件阻塞系統之前，您真的不知道到底是怎么回事。 以下查詢直接來自RolandoMySQLDBA的答案：

要了解使innodb緩沖池以KB為多少，請運行以下查詢：

SELECT SUM(data_length+index_length)/power(1024,1) IBPSize_KB
FROM information_schema.tables WHERE engine='InnoDB';

這是MB

SELECT SUM(data_length+index_length)/power(1024,2) IBPSize_MB
FROM information_schema.tables WHERE engine='InnoDB';

這是GB

SELECT SUM(data_length+index_length)/power(1024,3) IBPSize_GB
FROM information_schema.tables WHERE engine='InnoDB';

我還使用此處討論的tuning-primer腳本。 確實幫助我消除了MySQL的麻煩。 為了使數據有用，您需要將數據庫啟動，運行和活動至少2天，以便在實際服務器上至少有2天的實際流量之后，在生產服務器上運行該數據庫。

Answer 2

在進行mysql調整之前，您首先需要檢查是否由於ulimits或某些其他OS設置而導致內存分配失敗。

您能否粘貼以下命令的輸出-

1. ulimit -a
2. free -m

這些命令將打印有關在操作系統上設置的內存限制以及物理內存規格的信息。