У вас майже не вистачає оперативної пам’яті
У нас є близько 240 тис. Продуктів
Доступні оперативні пам’яті: 6 ГБ
Нитки: 32
У вас майже не вистачає оперативної пам’яті на кількість продуктів, які ви маєте. Як правило, ми рекомендуємо принаймні 2-4 Гб оперативної пам’яті на логічне ядро.
Якщо ви намітили можливе використання пам'яті:
- 64 PHP Нитки з
max_memory~ 768MB = 24 Гб
- 240 000 продуктів, ймовірно, означатимуть близько 15 ГБ місця InnoDB
- 64 PHP Нитки гарантують близько 128 підключень MySQL, як правило, це коштує близько 200 МБ за мінімум з'єднання
- Зберігання 240 тис. Продуктів в Redis AND
lzfстисненому - все одно буде споживати близько 6 Гб оперативної пам’яті
Таким чином, загальний обсяг оперативної пам’яті складає 70 Гб - ми навіть не згадували про ОС тощо.
Ваша апаратура жахливо не вказана . Я б запропонував прочитати цю статтю про налаштування сервера Magento, щоб дізнатися, як прогресувати.
Memcached не підтримує теги кешу
Якщо ви використовуєте Memcached (не проблема, його дуже висока продуктивність), ви зберігаєте теги кешу чи ні. Якщо у вас немає slow_backendвизначених значень, ви не зберігаєте теги, що в основному означає, що ваш кеш не може розрізняти будь-який з різних типів кешу - тому ви не зможете їх самостійно очистити.
Прочитайте це, http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/
Ми наполегливо пропонуємо перейти на Redis. Він має свої примхи та потребує значної тонкої настройки для великих магазинів. Але в цілому буде краще, ніж Memcached, з реальною перевагою підтримки кеш-тегів.
404-х та FPC
FPC має справжню проблему, насправді всі кешовані двигуни мають проблему з 404. Причина: будь-які старі URL-адреси, які ще скануються або пов’язані з ними, приземляться на сторінку, яка має повторити всю core_url_rewriteтаблицю, спробуйте знайти відповідність усім визначеним маршрутизаторам та просторам імен, перш ніж остаточно відмовитись і завантажити 404.
Потім кешуйте ресурс, який не має ніякого значення, і буде витрачати місце у вашому сховищі кешу. Ви, мабуть, знайдете, що величезна частина вашої пам’яті Memcached насправді з'їдається вмістом 404.
Маючи великі каталоги (240 тис. Товарів), ви, безсумнівно, матимете свою справедливу частку товарообігу, а отже, змін у URL-адресах, а згодом і багатьох 404-х.
FPC Invalidate vs. Clean
На даний момент - і за замовчуванням - поведінка FPC полягає в тому, щоб очистити кеш від змін, а не просто визнати недійсним запис кешу. Ми написали розширення, щоб змінити цю поведінку для магазину EE, щоб зробити саме те, що потрібно.
Ось короткий виправлення, щоб дати вам уявлення про те, як вирішити свою проблему.
app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
<observers>
<enterprise_pagecache>
<class>enterprise_pagecache/observer</class>
- <method>cleanCache</method>
+ <method>invalidateCache</method>
</enterprise_pagecache>
</observers>
</catalogrule_after_apply>
Не запускайте гусеницю
Якщо у вас достатньо пристойного підніжжя - ми не радимо запускати інструмент для сканування, це створює непотрібне навантаження. Люди / боти / сканери, які переглядають сайт, повинні зберігати кеш.
Але, щоб відповісти на ваше запитання, якщо ви заглянете у згаданий вище файл конфігурації - ви побачите графік кронів, визначений для вікна перегляду сканування.
Якщо ви можете дозволити собі черствий вміст
І в кінцевому підсумку, якщо у вас достатньо оперативної пам’яті. Ви могли б отримати користь від збільшення TTL вмісту, що зберігається у FPC - щоб зберегти кешовані дані довше.
У <full_page_cache>тегу в ./app/etc/local.xmlпросто визначте
<lifetimelimit>86400</lifetimelimit>
Час життя визначається в секундах. Вам потрібно досягти балансу між свіжістю вмісту, продуктивністю та кількістю місця для зберігання, яке ви фактично маєте.
Чому ви використовуєте сторонне розширення кешування з EE
Ви платите премію за FPC - що мені болісно сказати, дуже добре. То чому ви використовуєте сторонні альтернативи вгорі. Видали це.
Поставте так. Якщо ваш автомобіль працював погано - ви б просто додали ще один двигун у багажник, щоб компенсувати; чи просто зафіксувати двигун уже там?