Долгие запросы MySql

InstantCMS 2.X

Как бороться с задумчивостью мускула?

#1 8 ноября 2017 в 12:08
Частенько приходится наблюдать запросы в базу по несколько секунд. Например:
  1. /system/controllers/comments/model.php => 260 => modelComments->getCommentsCount()
  2. SELECT COUNT( i.id ) AS COUNT
  3. FROM cms_comments i
  4. WHERE (i.is_approved <> '1') AND (i.is_deleted IS NULL)
  5. Время выполнения 15.47301 секунд
  6. /system/controllers/comments/model.php => 296 => modelComments->getComments()
  7. SELECT i.*, r.score AS is_rated, u.nickname AS user_nickname, u.avatar AS user_avatar
  8. FROM cms_comments i
  9. LEFT JOIN cms_users AS u ON u.id = i.user_id
  10. LEFT JOIN cms_comments_rating AS r ON r.comment_id = i.id AND r.user_id='86'
  11. WHERE (i.is_approved <> '1') AND (i.is_deleted IS NULL)
  12. ORDER BY i.date_pub DESC
  13. LIMIT 0, 20
  14. Время выполнения 15.01130 секунд
При открытии категорий контента тоже случаются зависания секунд на десять
  1. /system/controllers/content/model.php => 2251 => modelContent->getContentItemsCount()
  2. SELECT COUNT( i.id ) AS COUNT
  3. FROM cms_con_anec i
  4. FORCE INDEX FOR ORDER BY (date_pub)
  5. INNER JOIN cms_con_anec_cats_bind AS b FORCE INDEX (item_id) ON b.item_id = i.id
  6. INNER JOIN cms_con_anec_cats AS c ON c.id = b.category_id
  7. WHERE (c.ns_left >= '2') AND (c.ns_right <= '3') AND (i.rating > '-20') AND (i.is_deleted IS NULL) AND (i.is_pub = '1')
  8. Время выполнения 1.73513 секунд
  9. /system/controllers/content/model.php => 2312 => modelContent->getContentItems()
  10. SELECT i.*, u.nickname AS user_nickname, f.title AS folder_title
  11. FROM cms_con_anec i
  12. FORCE INDEX FOR ORDER BY (date_pub)
  13. INNER JOIN cms_con_anec_cats_bind AS b FORCE INDEX (item_id) ON b.item_id = i.id
  14. INNER JOIN cms_con_anec_cats AS c ON c.id = b.category_id
  15. INNER JOIN cms_users AS u FORCE INDEX (PRIMARY) ON u.id = i.user_id
  16. LEFT JOIN cms_content_folders AS f ON f.id = i.folder_id
  17. WHERE (c.ns_left >= '2') AND (c.ns_right <= '3') AND (i.rating > '-20') AND (i.is_deleted IS NULL) AND (i.is_pub = '1')
  18. ORDER BY i.date_pub DESC
  19. LIMIT 0, 30
  20. Время выполнения 3.65383 секунд
Да, таблицы контента 150000 строк, а комментариев под миллион. Но!
Рядом на том же сервере, с теми же настройками базы данных остался старый сайт на первой ветке, с которого все перенесено.
Так там такой задумчивости не наблюдается. Все открывается меньше секунды.
Задумчивость Instantcms2, это баг или фича?
Или движок, рассчитан на десять статей и сто комментариев и не более?
#2 8 ноября 2017 в 12:23
Еще если у материала много комментариев (до 100 терпимо, но если 1000 — проблемы), то идет нагрузка.
Как вариант, можно загружать часть комментариев, а остальные при нажатии кнопки "Следующие комментарии". Предложение на ГитХабе
#3 8 ноября 2017 в 12:24

Задумчивость Instantcms2, это баг или фича?
Или движок, рассчитан на десять статей и сто комментариев и не более?

Ris
Задумчивости нет никакой. Есть несколько сайтов у клиентов с записями в типах контента в районе полумиллиона, — проблем нет. Вы уверены, что Mysql настроен корректно? Особенно если тип таблиц InnoDB (в единичке MyISAM).

Для комментариев можно сделать вот так:
  1. `ALTER TABLE `cms_comments` DROP INDEX date_pub;`
  1. ALTER TABLE `cms_comments` ADD INDEX (`is_approved`, `is_deleted`, `date_pub`);
В обновлении сделаю нормальные индексы для комментариев.
#4 8 ноября 2017 в 12:55
Fuze, на единичке блоги страдают, когда спамеры навтыкают по 82 тыс сообщений, если стоит модуль по блогам на главной, то туши свет. запросы сразу в slow и сайт открывается по полминуты. И еще запрос на теги при выборке target="blogpost"
#5 8 ноября 2017 в 13:05

Вы уверены, что Mysql настроен корректно?

Fuze
Совсем не уверен. У меня есть тестовый сервер с развернутой копией с дефолтными настройками VestaCp
Там два ядра и два гига оперативки, но результаты запроса примерно такие же:
  1. /system/controllers/comments/model.php => 260 => modelComments->getCommentsCount()
  2. SELECT COUNT( i.id ) AS COUNT
  3. FROM cms_comments i
  4. WHERE (i.is_approved <> '1') AND (i.is_deleted IS NULL)
  5. Время выполнения 6.17670 секунд
  6. /system/controllers/comments/model.php => 296 => modelComments->getComments()
  7. SELECT i.*, r.score AS is_rated, u.nickname AS user_nickname, u.avatar AS user_avatar
  8. FROM cms_comments i
  9. LEFT JOIN cms_users AS u ON u.id = i.user_id
  10. LEFT JOIN cms_comments_rating AS r ON r.comment_id = i.id AND r.user_id='86'
  11. WHERE (i.is_approved <> '1') AND (i.is_deleted IS NULL)
  12. ORDER BY i.date_pub DESC
  13. LIMIT 0, 20
  14. Время выполнения 13.72876 секунд
Категория контента:
  1. /system/controllers/content/model.php => 2251 => modelContent->getContentItemsCount()
  2. SELECT COUNT( i.id ) AS COUNT
  3. FROM cms_con_anec i
  4. FORCE INDEX FOR ORDER BY (date_pub)
  5. INNER JOIN cms_con_anec_cats_bind AS b FORCE INDEX (item_id) ON b.item_id = i.id
  6. INNER JOIN cms_con_anec_cats AS c ON c.id = b.category_id
  7. WHERE (c.ns_left >= '2') AND (c.ns_right <= '3') AND (i.rating > '-20') AND (i.is_deleted IS NULL) AND (i.is_pub = '1')
  8. Время выполнения 1.79360 секунд
  9. /system/controllers/content/model.php => 2312 => modelContent->getContentItems()
  10. SELECT i.*, u.nickname AS user_nickname, f.title AS folder_title
  11. FROM cms_con_anec i
  12. FORCE INDEX FOR ORDER BY (date_pub)
  13. INNER JOIN cms_con_anec_cats_bind AS b FORCE INDEX (item_id) ON b.item_id = i.id
  14. INNER JOIN cms_con_anec_cats AS c ON c.id = b.category_id
  15. INNER JOIN cms_users AS u FORCE INDEX (PRIMARY) ON u.id = i.user_id
  16. LEFT JOIN cms_content_folders AS f ON f.id = i.folder_id
  17. WHERE (c.ns_left >= '2') AND (c.ns_right <= '3') AND (i.rating > '-20') AND (i.is_deleted IS NULL) AND (i.is_pub = '1')
  18. ORDER BY i.date_pub DESC
  19. LIMIT 0, 30
  20. Время выполнения 7.23022 секунд
Мои настройки с тестового сервера (кэширование отключил специально):
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0

skip-external-locking
key_buffer_size = 16M
max_allowed_packet = 16M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M

#innodb_use_native_aio = 0
innodb_file_per_table

max_connections=70
max_user_connections=30
wait_timeout=10
interactive_timeout=50
long_query_time=5

#query_cache_limit = 2M
#query_cache_size = 64M
#query_cache_type = 1

tmpdir = /dev/shm

tmp_table_size=256M
max_heap_table_size=256M


#slow_query_log=1
#slow_query_log_file=/var/log/mysql-slow-queries.log



[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
Я пытался найти в сети рекомендации по ускорению медленных запросов, но там у каждого Абрама своя программа, многи советы противоречат друг другу и не один не привел к ускорению работы.

Может Вы расскажете, как правильно настроить мускул? Вот мои настройки с рабочего сайта:
# For advice on how to change settings please see
# dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html

[mysqld]
local-infile=0
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 768M
#
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
join_buffer_size = 128M
sort_buffer_size = 8M
read_rnd_buffer_size = 2M
query_cache_limit = 8M
query_cache_size = 64M
query_cache_type = 1
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock


# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
slow_query_log = OFF
slow-query-log-file=/var/www/neos/data/logs/mysqlslow.log
long_query_time= 10


log-queries-not-using-indexes

user=root
sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
kirkr,
В единичке модуль можно кэшировать, а спамеров отсекать (где-то видел плагин, который проверяет регистрации по спам-базам).
А тут ни спамеров, ни народу в онлайне, а открытие комментариев на модерацию загружает проц на 100% и на полминуты.
#6 8 ноября 2017 в 13:25
Ris, еще рекомендую посмотреть конфиг mysql, если дефолтный там куча ограничений. и проверку сделать таблиц в phpmyadmin есть диагностика
доп:
например

innodb_file_per_table

Ris
почему нет значения =1? если хотите все таблицы разложить в разные файлы

В таком случае, для каждой таблицы Mysql создаст отдельный файл данных и его описание на диске. Без этой настройки, Mysql хранит данные из всех таблиц в одном большом файле, который называется ibdata1.

Включение этого параметра даст такие преимущества:

При удалении таблиц, диск будет освобождаться, т.к. Mysql физически удалит файлы. Без этой настройки, файл ibdata1 не будет уменьшаться никогда (только расти).
Вы получите возможность хранить разные таблицы на разных устройствах (например, на сетевых дисках).
Можно физически перемещать отдельные таблицы между серверами, даже в случае работающего сервера и без использования Mysqldump.
Вы можете использовать сжатые форматы хранения данных.
Наличие нескольких файлов обеспечит возможности параллельной записи в каждый из них, а значит будет и определенный прирост в производительности.
#7 8 ноября 2017 в 13:28
kirkr,
Конфиг выше под спойлером.
#8 8 ноября 2017 в 14:44

Может Вы расскажете, как правильно настроить мускул? Вот мои настройки с рабочего сайта:

Ris

Надо запустить хотя бы mysqltuner — глянуть что покажет.
#9 8 ноября 2017 в 14:59

Надо запустить хотя бы mysqltuner — глянуть что покажет.

letsgo
Вот с тестового сайта:
>> MySQLTuner 1.6.0 — Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at mysqltuner.com/
>> Run with '--help' for additional options and output filtering
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.56-MariaDB
[OK] Operating on 64-bit architecture

— Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 873M (Tables: 125)
[--] Data in InnoDB tables: 544K (Tables: 17)
[!!] Total fragmented tables: 3
ERROR 1018 (HY000) at line 1: Can't read dir of './tmp/' (errno: 13)

— Security Recommendations -------------------------------------------
[OK] There is no anonymous account in all database users
[OK] All database users have passwords assigned
[!!] User 'admin_default@%' hasn't specific host restriction.
[!!] User '******_1@%' hasn't specific host restriction.
[!!] There is not basic password file list !

— Performance Metrics -------------------------------------------------
[--] Up for: 2h 18m 8s (4K q [0.580 qps], 249 conn, TX: 9M, RX: 563K)
[--] Reads / Writes: 92% / 8%
[--] Binary logging is disabled
[--] Total buffers: 544.0M global + 1.7M per thread (70 max threads)
[OK] Maximum reached memory usage: 547.3M (27.34% of installed RAM)
[OK] Maximum possible memory usage: 659.9M (32.97% of installed RAM)
[OK] Slow queries: 0% (11/4K)
[OK] Highest usage of available connections: 2% (2/70)
[OK] Aborted connections: 1.20% (3/249)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 7% (38 temp sorts / 484 sorts)
[!!] Joins performed without indexes: 64
[!!] Temporary tables created on disk: 39% (535 on disk / 1K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 10% (64 open / 594 opened)
[OK] Open file limit used: 12% (124/1K)
[OK] Table locks acquired immediately: 100% (3K immediate / 3K locks)

— MyISAM Metrics -----------------------------------------------------
[!!] Key buffer used: 79.8% (13M used / 16M cache)
[OK] Key buffer size / total MyISAM indexes: 16.0M/176.4M
[OK] Read Key buffer hit rate: 99.6% (9M cached / 38K reads)
[OK] Write Key buffer hit rate: 99.0% (2M cached / 22K writes)

— InnoDB Metrics -----------------------------------------------------
[--] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 128.0M/544.0K
[OK] InnoDB buffer pool instances: 1
[!!] InnoDB Used buffer: 5.04% (413 used/ 8191 total)
[OK] InnoDB Read buffer efficiency: 98.77% (33145 hits/ 33558 total)
[!!] InnoDB Write buffer efficiency: 0.00% (0 hits/ 1 total)
[OK] InnoDB log waits: 0.00% (0 waits / 153 writes)

— AriaDB Metrics -----------------------------------------------------
[--] AriaDB is disabled.

— Replication Metrics -------------------------------------------------
[--] No replication slave(s) for this server.
[--] This is a standalone server..

— Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Restrict Host for user@% to user@SpecificDNSorIp
MySQL started within last 24 hours — recommendations may be inaccurate
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
Temporary table size is already large — reduce result set size
Reduce your SELECT DISTINCT queries without LIMIT clauses
Set thread_cache_size to 4 as a starting value
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: bit.ly/1mi7c4C
Beware that open_files_limit (1024) variable
should be greater than table_open_cache ( 64)
Variables to adjust:
query_cache_size (>= 8M)
join_buffer_size (> 128.0K, or always use indexes with joins)
thread_cache_size (start at 4)
table_open_cache (> 64)
Вот с рабочего:
>> MySQLTuner 1.6.0 — Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at mysqltuner.com/
>> Run with '--help' for additional options and output filtering
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.7.19
[OK] Operating on 64-bit architecture

— Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 2G (Tables: 405)
[--] Data in InnoDB tables: 848K (Tables: 20)
[!!] Total fragmented tables: 22

— Security Recommendations -------------------------------------------
[!!] User '@localhost' is an anonymous account.
[!!] User '@******.ru' is an anonymous account.
ERROR 1054 (42S22) at line 1: Unknown column 'password' in 'where clause'
[OK] All database users have passwords assigned
ERROR 1054 (42S22) at line 1: Unknown column 'password' in 'where clause'
[!!] User '***@%' hasn't specific host restriction.
[!!] User '***@%' hasn't specific host restriction.
[!!] User '*****@%' hasn't specific host restriction.
[!!] There is not basic password file list !

— Performance Metrics -------------------------------------------------
[--] Up for: 5d 23h 17m 7s (7M q [14.860 qps], 205K conn, TX: 20B, RX: 1B)
[--] Reads / Writes: 92% / 8%
[--] Binary logging is disabled
[--] Total buffers: 232.0M global + 138.4M per thread (151 max threads)
[!!] Maximum reached memory usage: 4.3G (440.00% of installed RAM)
[!!] Maximum possible memory usage: 20.6G (2120.76% of installed RAM)
[OK] Slow queries: 0% (0/7M)
[OK] Highest usage of available connections: 19% (30/151)
[OK] Aborted connections: 0.73% (1498/205678)
[OK] Query cache efficiency: 35.3% (2M cached / 6M selects)
[!!] Query cache prunes per day: 61346
[!!] Sorts requiring temporary tables: 12% (16K temp sorts / 128K sorts)
[!!] Joins performed without indexes: 25335
[OK] Temporary tables created on disk: 21% (45K on disk / 212K total)
[OK] Thread cache hit rate: 99% (307 created / 205K connections)
[!!] Table cache hit rate: 4% (1K open / 49K opened)
[OK] Open file limit used: 34% (1K/5K)
[OK] Table locks acquired immediately: 99% (6M immediate / 6M locks)

— MyISAM Metrics -----------------------------------------------------
[OK] Key buffer used: 100.0% (8M used / 8M cache)
[OK] Key buffer size / total MyISAM indexes: 8.0M/628.9M
[OK] Read Key buffer hit rate: 99.9% (3B cached / 3M reads)
[!!] Write Key buffer hit rate: 85.8% (1M cached / 220K writes)

— InnoDB Metrics -----------------------------------------------------
[--] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 128.0M/848.0K
[OK] InnoDB buffer pool instances: 1
[OK] InnoDB Used buffer: 87.50% (7167 used/ 8191 total)
[OK] InnoDB Read buffer efficiency: 100.00% (243380756 hits/ 243382516 total)
[!!] InnoDB Write buffer efficiency: 0.00% (0 hits/ 1 total)
[OK] InnoDB log waits: 0.00% (0 waits / 245177 writes)

— AriaDB Metrics -----------------------------------------------------
[--] AriaDB is disabled.

— Replication Metrics -------------------------------------------------
[--] No replication slave(s) for this server.
[--] This is a standalone server..

— Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Remove Anonymous User accounts — there are 2 Anonymous accounts.
Restrict Host for user@% to user@SpecificDNSorIp
Reduce your overall MySQL memory footprint for system stability
Adjust your join queries to always utilize indexes
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: bit.ly/1mi7c4C
Beware that open_files_limit (5000) variable
should be greater than table_open_cache ( 2000)
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
query_cache_size (> 64M)
sort_buffer_size (> 8M)
read_rnd_buffer_size (> 2M)
join_buffer_size (> 128.0M, or always use indexes with joins)
table_open_cache (> 2000)
И главная страница открывается по четыре секунды всегда. Это сильно напрягает.
  1. /system/controllers/content/model.php => 2251 => modelContent->getContentItemsCount()
  2. SELECT COUNT( i.id ) AS COUNT
  3. FROM cms_con_anec i
  4. FORCE INDEX FOR ORDER BY (date_pub)
  5. WHERE (i.is_approved = '1') AND (i.is_deleted IS NULL) AND (i.is_pub = '1')
  6. Время выполнения 1.87533 секунд
  7. /system/controllers/content/model.php => 2312 => modelContent->getContentItems()
  8. SELECT i.*, u.nickname AS user_nickname, f.title AS folder_title
  9. FROM cms_con_anec i
  10. FORCE INDEX FOR ORDER BY (date_pub)
  11. INNER JOIN cms_users AS u FORCE INDEX (PRIMARY) ON u.id = i.user_id
  12. LEFT JOIN cms_content_folders AS f ON f.id = i.folder_id
  13. WHERE (i.is_approved = '1') AND (i.is_deleted IS NULL) AND (i.is_pub = '1')
  14. ORDER BY i.date_pub DESC
  15. LIMIT 0, 30
  16. Время выполнения 2.18498 секунд
#10 8 ноября 2017 в 15:36
Не перезапуская mysql посмотреть через phpmyadmin переменные и те что красные оптимизировать
#11 8 ноября 2017 в 15:52
Ris, попробуйте почитать тут

Вот мои настройки с рабочего сайта:

Ris
Судя по конфигу — у вас дефолт. Из того, что написано я бы query_cache_limit уменьшил.
Основная директива это key_buffer_size, которая у вас по умолчанию (она не задана). Если таблицы у вас innodb, то также стоит указать innodb_buffer_pool_size. Это если вкратце совсем. Вот тоже неплохая статья.

В целом, по проблеме комментариев, указанные мной выше индексы решат проблему, но разумеется для такой большой базы нужно подстроить MySQL.
#12 8 ноября 2017 в 16:28
Вообще конечно так наугад не настроишь, надо смотреть статистику и тд. Но примерно так pastebin.com/9XqfBcAr (обязательно бекап сохранить оригинал my.cnf ) и дальше уже тестировать, по результатам что куда поправлять. Желательно тестировать и уже изменять по ходу работы. Не забудьте службу перегрузить естественно.
#13 7 февраля 2018 в 20:31
Что-то я в попытках разобраться в этих тормозах совсем запутался.
У меня уже нервный тик и глаз дергается. shock
Включено кэширование на 2 минуты в memcached, но почему-то вместе с кешем все равно производятся запросы в базу.
Вот это из одной отладки:
  1. /system/controllers/content/model.php => 2251 => modelContent->getContentItemsCount()
  2. SELECT COUNT( i.id ) AS COUNT
  3. FROM cms_con_anec i
  4. FORCE INDEX FOR ORDER BY (date_pub)
  5. WHERE (i.is_parent_hidden IS NULL) AND (i.rating > '-20') AND (i.is_deleted IS NULL) AND (i.is_pub = '1')
  6. Время выполнения 1.69741 секунд
  7. /system/controllers/content/model.php => 2312 => modelContent->getContentItems()
  8. SELECT i.*, u.nickname AS user_nickname, f.title AS folder_title
  9. FROM cms_con_anec i
  10. FORCE INDEX FOR ORDER BY (date_pub)
  11. INNER JOIN cms_users AS u FORCE INDEX (PRIMARY) ON u.id = i.user_id
  12. LEFT JOIN cms_content_folders AS f ON f.id = i.folder_id
  13. WHERE (i.is_parent_hidden IS NULL) AND (i.rating > '-20') AND (i.is_deleted IS NULL) AND (i.is_pub = '1')
  14. ORDER BY i.date_pub DESC
  15. LIMIT 0, 30
  16. Время выполнения 1.71915 секунд
И в то же время использовался кэш:
/system/controllers/content/model.php => 576 => modelContent->getContentFields()
content.fields.anec.7021627cb7c7d6632c0cc7140e2e1100
Время выполнения 0.00054 секунд
/system/controllers/content/model.php => 2251 => modelContent->getContentItemsCount()
content.list.anec.7e5098981456bab4754285a1f92ad413
Время выполнения 0.00036 секунд
/system/controllers/content/model.php => 2312 => modelContent->getContentItems()
content.list.anec.a7d64131ad6086d053170779df8e9ce0
Время выполнения 0.00038 секунд
Такое ощущение, что кэш сохраняется, но не используется.
Что, черт побери, можно еще проверить, чтобы оно зашевелилось?
#14 7 февраля 2018 в 23:34
Есть ли у вас база — innodb_memcache
Если нет то вы не насторили связку memcached c mysql
зайдите в мускуль под рутом и выполните:
source /usr/share/mysql/innodb_memcached_config.sql;
install plugin daemon_memcached soname "libmemcached.so";
или если стоит mysql и используется innodb то как вариант перейти на mariadb 10.2 и запустить rockdb
#15 7 февраля 2018 в 23:40
eoleg,
У меня MyISAM.
Если есть смысл поменять на innodb — напишите, пожалуйста, в чем смысл.
На тестовом сервере переконвертил базу в innodb — особого ускорения не увидел.
Вы не можете отвечать в этой теме.
Войдите или зарегистрируйтесь, чтобы писать на форуме.
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.