我试图调优我的Magento以获得最佳的性能。
我正在一个4GB的RAM上运行nginx,php和mysql,8 8CPU核心虚拟机有4GB的RAM。
我运行了Mysql调优Primer,除了我的Table之外,一切看起来都很好:
TABLE CACHE
Current table_open_cache = 1000 tables
Current table_definition_cache = 400 tables
You have a total of 2510 tables
You have 1000 open tables.
Current table_cache hit rate is 3%
, while 100% of your table cache is in use
You should probably increase your table_cache
You should probably increase your table_definition_cache value.
和来自mysqltuner
[!!] Table cache hit rate: 9% (1K open / 10K opened)
[!!] Query cache efficiency: 0.0% (0 cached / 209 selects)
my.cnf文件中的相关设置:
table_cache = 1000
query_cache_limit = 1M
query_cache_size = 64M
问题是,不管我把我的table_cache提高到什么程度,它似乎几乎马上就会被消耗掉。这对Magento来说很正常吗?看上去很高吗?
有人知道我能做些什么来改善这个问题吗?
谢谢,
边缘
发布于 2012-10-11 16:35:10
检查MySQL配置的查询缓存类型设置:
类型
如果将其设置为0或2,则它将要么不缓存任何查询,要么只缓存您专门要求缓存的查询。这意味着Magento必须显式地请求缓存的查询结果(我不确定它能做到这一点)。如果将其设置为1,则它将缓存所有查询,但不显式请求不请求查询缓存的查询除外。
表缓存是指潜在的打开的文件指针。它可以很快地被消耗,并且只会在需要的时候滚出未使用的条目。来自MySQL文档
table_cache和max_connections系统变量影响服务器保持打开的最大文件数。如果增加其中一个或两个值,则可能会遇到操作系统对打开的文件描述符的每个进程数施加的限制。许多操作系统允许您增加打开文件的限制,尽管不同系统的方法差别很大。请参阅您的操作系统文档,以确定是否有可能增加限制,以及如何提高限制。 table_cache与max_connections有关。例如,对于200个并发运行的连接,您应该有至少200 * N的表缓存大小,其中N是每个连接在执行的任何查询中的最大表数。您还必须为临时表和文件预留一些额外的文件描述符。 确保您的操作系统能够处理table_cache设置所隐含的打开文件描述符的数量。如果table_cache设置得太高,MySQL可能会耗尽文件描述符,拒绝连接,无法执行查询,而且非常不可靠。您还必须考虑到,对于每个唯一的打开表,MyISAM存储引擎需要两个文件描述符。您可以使用mysqld的-打开文件限制启动选项来增加MySQL可用的文件描述符的数量。见C.5.2.18节,“未找到文件和类似的错误”。 打开的表的缓存保持在table_cache条目的级别。默认值为64;可以将-table_cache选项更改为mysqld。注意,为了执行查询,MySQL可能会临时打开更多的表。 MySQL关闭未使用的表,并在以下情况下从表缓存中删除它: 当缓存已满且线程试图打开不在缓存中的表时。 当缓存包含超过table_cache条目和缓存中的表不再被任何线程使用时。 当发生表刷新操作时。当某人发出FLUSH TABLES语句或执行mysqladmin刷新表或mysqladmin刷新命令时,就会发生这种情况。 当表缓存被填满时,服务器将使用以下过程来定位要使用的缓存项: 释放当前未使用的表,从最近使用最少的表开始。 如果需要打开一个新表,但缓存已满且无法释放表,则缓存将在必要时临时扩展。当缓存处于临时扩展状态且表从已使用状态变为未使用状态时,表将关闭并从缓存中释放。
https://stackoverflow.com/questions/12745063
复制相似问题