100napb

все верно иногда оптимизатор mysql слишком придирается. норм. это его работа )) если не ошибаюсь, того же результата можно добиться через предварительное выполнение set session optimizer_switch = 'derived_merge=off';

Эм.. Синтаксис там проверять что ли? Ну так за это я спокоен логика и дополнительные проверки сильно зависят от набора данных. На тестовой базе проверял, конечно, благо есть возможность. Другое дело, что у ТС все может быть намного сложнее, чем на примитивном тесте. На всякий случай отредактировал пост выше, добавив дополнительные условия проверки, что бы учесть больше вариантов. P.S.: вероятно, у нас разные версии\настройки сервера БД. Если не ошибаюсь, за подобные проверки отвечает параметр optimizer_switch = 'derived_merge=off'; Ну или phpmyadmin слишком придирчивый. В любом случае, это не шибко важно... У меня выполняется без проблем, например. На самом деле, это типичная "ошибка", типа, а-та-та, некрасиво так явно читать из той же таблицы, которую меняешь. Обычно решается тем, что бы загнать селект в подзрапрос или убрать его join, что бы оптимизатор мускуля стал считать таблицу из подзапроса временной и перестал ругаться

Понятно. Видимо, я не учел, что у Вас могут быть товары с привязкой более чем к 2 категориям. Исправляемся. Итак, что бы появилось понимание, а не ленивая копипаста. 1. Установим 64 категорию для всех товаров, у которых статус наличия = 5 И существует всего одна привязка к категории И эта привязка не к категории 64 2. Зеленый подзапрос находит все товары в таблице product_to_category, у которых а) статус наличия = 5 б) существует более чем одна привязка к товарной категории. Фиолетовая же часть запроса удаляет привязки к категориям для найденных в подзапросе товаров КРОМЕ тех случаев, когда товарная категория 64. Таким образом, после выполнения скрипта в таблице не должно остаться дублей. Но остаются привязки товаров к не 64 категории 3. В принудительном порядке назначаем всем товарам со статусом наличия = 5 64 категорию.

Так... кажется Чукча не зря сомневался. Ладно хоть бэкапы есть и желание экспериментировать )) Вы первый-то скрипт прогнали прежде чем этот апдейт выполнять? Он должен был дубли убрать.

тогда просто во втором скрипте добавьте одно условие - нужный статус наличия товара. И все будет ок. Сначала удалить дубли, затем сделать 64 категорию. Должно сработать UPDATE oc_product_to_category p2c JOIN oc_product p ON p.product_id = p2c.product_id SET p2c.category_id = 64 WHERE p.stock_status_id = 5 AND p2c.category_id != 64;

Здравствуйте! Надеюсь, Вы максимально точно изложили задачу. В любом случае, рекомендую сделать бэкап таблицы product_to_category прежде чем будете выполнять скрипты ниже. 1. Действительно, "Проблема в том, что у части товаров данная категория уже присвоена". Из-за этого нельзя просто так взять и всем товарам в таблице product_to_category присвоить одну категорию - ограничение уникальности по первичному ключу не позволит (нельзя, что бы в таблице для одного и того же товара существовало более одной записи вида ид_товара + ид_категории). По этому, начинаем с того, что удалим из таблицы product_to_category все записи об одном и том же товаре, кроме одной. 2. Ну дальше, как Вы и просили, присваиваем всем товарам 64 категорию. Правда, мы снова можем нарваться на ограничение уникальности. Но тут без уточнения с Вашей стороны чего-либо пока писать не буду. Вы реально хотите что бы у ВСЕХ товаров в магазине была 64 категория?

золотые слова! Но если уж прям очень-очень хочется, то [*devil*]

Однако, по-прежнему нужно как-то выводить еще и хидеры\футеры, хлебные менюшки с корзинами и прочую вроде как повторяющуюся, но, все-таки, динамическую информацию. Пофантазируем, откуда их можно брать, если не из базы. Ок, про query_cache со стороны мускуля мы забыли. Хотя можно точечно развесить на конкретные запросы при type = ondemand.. Так же как и про кеэширование страницы целиком. Забыли про кэширование непосредственно результатов запросов в то или иное хранилище, будь то файлик, редис, или мемкеш. Всякие server side include'ы ? Инициализировать и хранить в глобальных переменных? )))) А может, а может... аякс? Даешь, что бы менялось только то, что должно изменится. Главное сео не прибить случайно. Последний вариант с аяксом, а? Этакий лэзи-лоад на весь движок Пожалуй, с этим можно только согласиться. Вот, к примеру: 100, да бог с ним, пусть будет 200 запросов к базе на страницу. Вы писали, что на одном сервере БД крутится 100доменов. Допустим, (1000 уников в сутки с домена * 10 страниц глубины просмотра с уника * 100доменов * 200 запросов к базе со страницы) / 24 часа / 60 минут / 60 секунд ~~~ 2300qps. Плюс еще боты - пусть столько же. Пусть будет почти придуманные 5kqps. Не ентерпрайз ведь даже или прям хайлоад. Да, круто. Да, от таких задач у большинства предлагаемых vps виртуальные ядра перегреются. Но это не проблема, согласитесь. Если прям не хотите кэшировать, то упрощайте. Делайте их быстрее, легче, что бы снизить нагрузку. Статикой замените, если хотите ))) Слоулог тут советовать бессмысленно. performance_schema = on и explain для отладки: по самым медленным, по самым частым, по тем, что делают фуллскан, по тем, что вешают долгие блокировки, по тем, что свапятся на диск...

@gregoro чем закончилось-то? Вижу, что spf-запись теперь проходит проверки. Рассылка то же успешно работает? Интересно ж.

Меню - дополнения - менеджер обновлений. Нажмите на синие стрелочки "обновить". И чудесным образом ситуация повториться вновь. Инфа 99% в опенкарте существует такой механизм, как OCMOD. Модификаторы. Что он делает и зачем нужен? Что бы прозрачно вносить изменения в файлы скриптов, не внося правки непосредственно в сами файлы системы. И так же прозрачно и легко эти изменения отменять. Допустим, Вам нужно что-то изменить в том или ином месте. Дописать новый функционал или изменить существующую логику. И иногда бывает удобно не вносить изменения напрямую в файл. А применить небольшой модификатор, который найдет в нужном файле нужное место и внесет нужные изменения. И уже измененный код, с правками, помещается в папку modifications. Оттуда файл подключаются и работает вместо основного, который остается без изменений. Почти повсеместно механизм модификаторов используется в создании и установке новых модулей для опенкарта. Как только в главном меню опенкарта вы обновляете модификаторы, все текущие файлы с внесенными правками удаляются (они же временные) и пересобираются снова. Это нужно, например, когда вы изменили какой-то модификатор или добавили новый. Так что, все в порядке. Удаление и создание новых файлов в этом папке - обычное дело

сколько по времени и как длится процедура обновления прайса? как проверяли? почему сделали вывод, что не связано? Может 20минут ежечасно это обновление прайса бомбит Вам myisam табличку с продуктами десятками тысяч апдейтов с соответствующими блокировками - это одно. А может, несмотря на вменяемое железо, у Вас ужасно настроен сервер БД, без той же, например, low-priority-updates или с от балды проставленными буферами и прочими параметрами... а еще может... Лучше один раз увидеть, чем сто раз услышать. Если гадание не поможет, то с радостью готов буду посмотреть.

дожимайте ее. Это их работа. Вы им денежку платите, как никак. P.S.: как вариант, перечисление серверов-отправителей с указанием директивы ip4 не требует проверки dns. Ввиду этого, можно топорным методом часть айпишников прописать, без ограничений.

Обратите внимание, что при попытке разрешить spf-запись getcourse.ru она "разворачивается" в еще несколько spf-записей. https://mxtoolbox.com/SuperTool.aspx?action=spf%3agetcourse.ru&run=networktools и если копнуть еще чуть глубже, и посмотреть, что скрывается за getmailing.ru, то сразу все становится понятно нужно сокращать список. может быть будет достаточно вместо getcourse.ru прописать getcourses.ru А вообще, лучше всего, конечно, уточнить в поддержке самого сервиса.

Если прям очень интересно, откуда ноги растут, и есть желание разобраться во всем самому, то открываете /system/library/cart/cart.php и смотрите хотя бы в тот же стандартный метод корзины getProducts(). Он возвращает массив товаров, содержащихся в корзине. С этим методом и полученным массивом товаров, как правило, работают все остальные модули, отвечающие за процесс оформления заказа. Так вот. В этом массиве для каждого товара имеется булевый элемент stock, который равен true, когда товар есть в наличии. Ну и наоборот. При этом, нет явного запрета на добавление товара в корзину с нулевыми или отрицательными остатками, что как бы норм, бывают же предзаказы всякие. И уже потом, в процессе оформления заказа, будет проводится проверка по этому полю stock и, в случае чего, выдаваться уведомление клиенту, что каких-то там товаров нет в наличии и завершить заказ низя. Ну какое-либо иное действие. Не суть. Если Вы хотите например, что бы была проверка на кол-во еще при добавлении товара в корзину, и если этот функционал реализован в шаблоне, то прежде всего, стоит изучить, каким образом изменена у Вас эта логика (скорее всего ocmod'ами). Открываете /system/storage/modification/system/library/cart/cart.php и смотрите, что там происходит. Можно для наглядности и понимания выводить содержимое корзины куда-нибудь в лог и смотреть. например, вставив прям в файл /system/storage/modification/system/library/cart/cart вот такую команду Еще может быть какой-нибудь кэширующий модуль. Который клиенту показывает еще доступный товар, в то для Вас, как админа, кэш не работает. Еще может быть в карточке товара не установлен верные статусы товаров, когда нет в наличии Еще может быть в том же манимейкера не настроены Преимущества товаров > Статус склада на вкладке товар.

Здравствуйте! Уточните пожалуйста, правильно ли я понимаю, что модуль Jet Cache появился уже после того, как было выявлено увеличение нагрузки на БД и, как бы, был призван решить эту проблему? А что случилось 25го числа? Судя по графику, тут прямо бурный всплеск. Клиенты повалили на сайт или что-то установили\делали с сайтом? может быть какой-нибудь парсер товаров, или... ? По факту же, есть явное указание проблемы + в Вашем логе хостер заботливо сгруппировал и отсортировал наиболее тяжелые и дорогие до СР запросы. А это прямое указание к действию - профилировать эти запросы и выяснять, есть ли необходимые индексы, которые используются для join-связки таблиц. Делов на 15 минут. Если не справитесь - пишите в личку. Помогу. Это правда не сложно, да и запросы в логе выглядят вполне себе понятными

Хах)) С таким подходом не поспоришь. Пожалуй, это очевидно, но почти все сообщения выше - это как оферта между строк, типа, "я готов помочь! и предлагаю свои услуги. Зацените - я компетентен". Просто эти предложения своих услуг не такие толстые ))

Конкретные вопросы любят конкретных ответов: 1. Верно. Судя по описанной Вами ситуации, у Вас fcgi запускается через apache + mod_fastcgid. Так вот FastCGI - это лишь способ запуска php. Но php-fcgid действительно по-другому работает с памятью и отличается тем, что процесс php не завершаеся после обслуживания клиента\выполнения работы, а ждет нового. Таким образом, обработчик php при FastCGI запущен всегда, и нет нужды тратить время на его запуск - ему достаточно только выполнять полезную работу. И за это надо платить постоянным выделением памяти. Тот же php-fpm работает по-другому. Более экономно, что важно в Вашем случае ) 2. Можно конечно. Проект не выглядит прямо супер-большим. И 1гб озу вполне должно хватить если не на супер-быструю, то на стабильную работу всех служб и сервисов - факт. 3. Есть такие ребята, конечно. Чуть выше, например очень годный совет от сразу двух: @Designer и @EvaSystems У меня, например, громадный опыт работы базами данных, mysql - в том числе. Ну а с настройками веб-серверов уже приходится "дружить" за компанию, т.к. они почти всегда соседствуют с сервером БД и делят с ним ресурсы\вместе отвечают за итоговую стабильность и производительность проекта. Короче говоря, с удовольствием могу помочь настроить сервер БД должны образом, отпрофилировать и оптимизировать любые медленные запросы. Памяти всем хватит) Пишите, если интересно.

Прошу прощения, что вклиниваюсь - топик не мой и к модулю я не имею никакого отношения. А вот с базами работаю давно и плотно. Потому кратенько прокомментирую Банальный вопрос, который Вы почему-то не осветили: какой объем данных (кол-во строк и вес таблицы в МБ) у Вас содержится в таблицах модуля? А сколько вся база весит? Вопрос лишь каким способом делать бэкапы. Если речь идет о штатных инструментах базы данных (mysqldump), то это одно. Тут проблем может быть крайне мало, особенно на малых и средних проектах. Запихал в крон небольшой скрипт с бэкапом и все: какую хочешь глубину резервных копий настраивай, куда хочешь копирую потом копии. Место на диске закончится - это чаще всего происходит )) или таблицы вдруг повреждены. В остальном всегда без проблем: +\- только необходимое время на сам бэкап. Если же речь идет об обработке процедуры бэкапа через некий php-скрипт, то, разумеется, Вы получаете те или иные ограничения, связанные с окружением PHP: лимиты выделяемой памяти, таймауты и прочее. Надо понимать, что универсального решения тут не существует - параметры нужно подбирать экспериментальным путем. И Вы совершенно верно начали их менять и увеличивать лимиты - молодец Ведь на проекте с суммарным объемом данных в 50мб - это одно; а если все таблички весят десятки гигабайт - другое (тут возможно уже потребутся совсем другие решения (поднимать слейв-базу, например, или использовать специализированные утилиты) Увеличение мемори_лимит - это не про mysql, а про php. Мускуль имеет совершенно иные настройки и их важно уметь правильно подобрать, что бы получать максимум производительности при разумном использовании серверных ресурсов. К слову, с радостью настрою Вам mysql. Напишите в ЛС, если интересно. Опыт подобных работ действительно большой. Каждые две минуты? Серьезно? Он вообще успевать сдампить один раз, прежде чем начинать второй?

мне этот мануал уже несколько раз пригодился. Советую и Вам в закладки добавить) сложно быть уверенным на 146%, так как не каждый день подобное делаешь, но... попробуйте добавить к записи вот это: mx a:sub.mydomen.ru include:getcourse.ru или лучше просто mx include:getcourse.ru (айпишник ведь тот же, на одном сервере и домен и поддомент?) что бы стало так v=spf1 mx ip4:185.219.40.111 include:getcourse.ru include:_spf.yandex.net include:spf.unisender.com ~all ну и проверяйте сразу веселым тестером

Если речь идет о форме заказа в админке, то 1 смотрите в сторону /admin/controller/sale/order.php 2. настройке модуля Simple, в самом низу, есть форматы адреса. Может быть там стоит попробовать. 3. пока писал, выше предложили интересный вариант, о котором и не знал даже ))

Раньше у Вас не было ssl сертификата и сайт работал на "обычном" http ИЛИ изменилось доменное имя? Смотрите что в консоли пишет В любом случае, совет выше, похоже, совершенно верный. Ну или гуглите типа такого

В таком случае, при оформлении заказа не произойдет автоматического списания товаров со склада. Только при ручном изменении статуса. Наверное, при некоторых бизнес-моделях это норм. Но чисто гипотетически, при такой настройке возможна ситуация, когда на складе 1 шт на остатке есть , и на эту штуку 20 заказов за ночь наоформляют клиенты, т.к. первый же заказ не обнулит остаток. А завтра с утра будем им звонить и извиняться.

Если а) у Вашей позиции с кол-ом "1" в карточке товара на вкладке данные стоит "вычитать со склада" б) статус новых заказов = статус из группы "обрабатываемые" то списание товаров должно произойти сразу же в момент создания заказа. Повторного списания не произойдет после смены статуса из обрабатываемых в завершенные Это еще цветочки. Не ягодки. И уж тем более - не шаманство

Какой статус заказу у Вас присваивается сразу же при его создании? должен быть один из группы "обрабатываемых"

Как вариант, браузер на телефоне закэшировал какой-то промежуточный вариант таблицы стилей. Более корректно проверку делать в приватном режиме телефонного браузера: нажимаете + по центру, а затем слева выбираете приватный режим (фон браузера должен стать темным).