3

在以下狀態中,我打開的文件數量爲'95349'。 這個值正在迅速增加。在mysql中打開文件和打開文件的區別

的MySQL>show global status like 'open_%';

Open_files = 721個

Open_streams = 0

Open_table_definitions = 706個

Open_tables = 741個

Opened_files = 95349

Opened_table_definitions = 701個

opened_tables的= 2851

也看到這一點。

的MySQL>show variables like '%open%';

have_openssl = DISABLED

innodb_open_files = 300

open_files_limit = 8502

table_open_cache = 4096

max_connection = 300

是否與打開的文件和打開的文件有任何關係。由於增加了opens_files的值,會不會有任何性能問題。這是一個8 GD RAM和500 GB硬盤的處理器服務器:Intel(R)Xeon(R)CPU E3-1220 V2 @ 3.10GHz。這是一個專用的mysql服務器。

這裏該命令

的ulimit -n;

1024是服務器經常掛計數

。使用一些在線工具我已經優化了一些參數。需要知道還有什麼應該優化?在什麼情況下,打開的文件數量會減少?是否有必要打開的文件數量應該在一定的限度內。如果是的話如何找到適合我的服務器的限制。如果不清楚某些地方,請通過提出更多問題來幫助我。

+0

此問題屬於[ServerFault](http://serverfault.com/)。 – wallyk

回答

2

Opened_files是自上次重新啓動mysqld以來您打開表的次數的計數器(請參閱狀態變量Uptime,表示自上次重新啓動以來的秒數)。

Open_files不是計數器;這是當前打開文件的數量。

如果您的Opened_files計數器快速增加,則可以通過增大table_open_cache的大小來提高性能。

有關該變量對性能的影響(約過高設置它的一些注意事項)的一些提示,請參閱:


回覆您的意見:

你誤會了櫃檯的目的。它總是增加。它計算自上次重新啓動mysqld以來發生特定操作的次數。在這種情況下,打開一個表格的文件。

在計數器中具有很高的價值並不一定是問題。這可能意味着你的mysqld已經運行了很多天或幾周而沒有重新啓動。因此,您必須查看與正常運行時間相比的那個數字(即,MySQL狀態變量Uptime,而不是Linux正常運行時間)。

更有意義的是計數器增加的速度,即它在給定的時間間隔內增長得有多快。這可能表明您正在迅速重新開放表格。

通常,MySQL不應該重新打開表格,因爲它爲每個表格保留了一個開放的表格句柄。但它只能有限數量。這就是table_open_cache的用途。在你的情況下,你的MySQL實例可以「記住」它一次已經打開4096個表。如果您需要打開另一個表格,它將關閉其中一個文件描述符並打開您請求的表格。因此,如果您有數千個表(或表的分區),並且您可以快速訪問它們的各種各樣的表,您可以看到該表打開緩存中的大量週轉。這將表示計數器 Opened_tables快速增加。

因此,調整table_open_cache的上限意味着MySQL可以保留更多的開放表句柄,並且可能會降低更新率。

+0

我發現只有當從應用程序調用特定的複雜查詢時,opens_files數纔會增加。我會盡量優化查詢。但我有疑問。關於opens_files,我的目標應該是什麼?我應該把這個數字歸零。 – siva

+0

我發現根據來自「Percona MySQL for MySQL」的報告,對於這種硬件配置,我無法再增加table_open_cache。所以如果我優化複雜的查詢,我的opens_files數是否會保持爲0.(只是想了解在mysql性能調優中監控opens_files數的目的)。注意:open_file穩定在限制之下。所以我沒有問題。 – siva

0

因此,解決方案是增加我的硬件(特別是RAM),以便我能夠將table_open_cache增加到4096以上或優化查詢。