在以下状态我打开文件计数为’95349′.
这个值正在迅速增加.
MySQL的>显示全局状态,例如’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>显示’%open%’等变量;
have_openssl =已禁用
innodb_open_files = 300
open_files_limit = 8502
table_open_cache = 4096
和
max_connection = 300
与打开文件和打开的文件有任何关系.因open_files值增加会有任何性能问题.这是一台8 GD RAM和500 GB硬盘的服务器,带处理器:Intel(R)Xeon(R)CPU E3-1220 V2 @ 3.10GHz.它是一个专用的mysql服务器.
这里是命令
ulimit -n;
1024是计数
服务器经常挂起.使用一些在线工具我已经优化了一些参数.需要知道还应该优化什么?在什么情况下打开的文件数量会减少?是否有必要打开文件计数应该在一定限度内.如果是这样,如何找到我的服务器的适当限制.如果不清楚某些地方请通过提出更多问题来帮助我.
最佳答案 Opened_files是自上次重启mysqld以来打开表的次数的计数器(请参阅状态变量Uptime自上次重启以来的秒数).
Open_files不是一个计数器;这是当前打开的文件数.
如果您的Opened_files计数器快速增加,您可以通过增加table_open_cache的大小来提高性能.
有关此变量的性能影响的一些提示(以及有关将其设置得过高的一些注意事项),请参阅:
> http://www.mysqlperformanceblog.com/2009/11/16/table_cache-negative-scalability/(这里描述的问题似乎终于在MySQL 5.6中得到了解决)
你的意见:
你误解了柜台的目的.它总是增加.它计算自上次重启mysqld以来特定操作发生的次数.在这种情况下,打开表的文件.
在柜台中具有高价值不一定是个问题.这可能意味着你的mysqld已经运行了很多天或几周而没有重启.因此,与正常运行时间相比,您必须查看该数字(即,MySQL状态变量正常运行时间,而不是Linux正常运行时间).
更有意义的是计数器的增加率,即在给定的时间间隔内增长的速度.这可能表明您正在快速重新开放表格.
通常,MySQL不必重新打开表,因为它为每个表保留了一个打开的表句柄.但它只能有一定数量的那些.这就是table_open_cache的用途.在您的情况下,您的MySQL实例可以“记住”它已经一次打开多达4096个表.如果您需要打开另一个表,它会关闭其中一个文件描述符并打开您请求的表.
因此,如果您有数千个表(或表的分区)并且您可以快速访问各种表,那么您可以在该表中看到大量的营业额打开缓存.这将由计数器Opened_tables迅速增加来表明.
因此,调整table_open_cache的大小意味着MySQL可以保留更多的打开表句柄,并可能降低更新率.