Jump to content

100napb

Пользователи
  • Content Count

    307
  • Joined

  • Last visited

Community Reputation

76 Очень хороший

9 Followers

About 100napb

  • Rank
    Базы данных, SQL

Информация

  • Пол
    Мужчина
  • Интересы
    SQL

Recent Profile Visitors

3,937 profile views
  1. как вариант, collation был разным. из-за этого запросто может быть content_top != content_top и все то, что Вы и ТС описывали. Было бы неплохо взглянуть на буржуйский скрипт - чего он там с таблицами делает. MyISAM - > InnoDB конвертнуть проще простого. Хоть так, например.
  2. Вы определитесь, какое из этих утверждений истинное. Может, конечно, я Вас наверно понимаю, но Вы вроде как сами обозначили проблему: зашел в карточку товара, а картинки нет. Anyway, добавить особо нечего: никакие приведения картинки не крадут) либо их что-то при каких-то обстоятельствах удаляет, либо веб-сервер не отдает, либо... может быть еще какой-нибудь js-скрипт у Вас работает для встраивания картинок в html-код (дайте ссылку на сайт в личку, пж) и иногда работает некорректно...
  3. Важно понимать, картинка\кэш картинки физически пропадает с сервера (проверить элементарно - просто попробуйте открыть ее по прямой ссылке, выудив ее из html) или же она на месте, открывается по прямой ссылке но в карточке товара иногда не отображается? Причины и способы решения, разумеется, будут разными для обоих вариантов. Так, для первого надо будет смотреть в сторону того как и что может очищать кэш картинок; во втором случае - смотреть в настройки веб-сервера (nginx) - вполне возможно, то он не успевает обработать все запросы на отдачу статики и их часть отсекается по таймауту (такое бывает при некорректной настройке ssl).
  4. Раз уж добрались до таблицы product_image, посмотрите какое там крайнее значение id. Вдруг в диапазон int не умещается.
  5. на случай, если пропустили. вдруг то что нужно. Во всяком случае, можно и вручную баланс карточек менять, так и автоматом - при смене статусов заказов
  6. а.. теперь теплее. в таком случае, может быть так? SELECT (SELECT t2.meta_h1 FROM table_2 t2 WHERE t2.lang_id = 1) meta_h1, (SELECT description FROM table_1 t1 WHERE t1.lang_id = 1 AND t1.store_id = 2) descriptions
  7. эм... так вроде бы так SELECT meta_h1, description FROM table_1 t1 JOIN table_2 t2 ON t1.language_id = t2.language_id WHERE t1.language_id = 1 AND t1.store_id = 0
  8. в админке, в левом меню Journal - Header - Main Menu - Desktop или Mobile (они разные) - в самом низу выбираете Dropdown Type (скорее всего Вам интересны будут либо Mega Menu, либо FlyOut) если FlyOut - то выбираете уже конкретный модуль для отображения из списка Journal - modules - Flyout menues если мегаменю, то прямо там же, в Builder'e создаете макет\структуру и назначаете конкретные блоки
  9. если с ходу, то: а) банальный INSERT ~ 1000 записей - это 1000х инсертов или один инсерт вида insert into table_name (id, val) values(1,1),(1,2),(1,3),… ? б) установленный уровень фиксации транзаций (innodb_flush_log_at_trx_commit 2) накладывает серьезные ограничения на скорость изменения данных; если нет жестких требований, обусловливающих необходимость именно такого уровня, то смело ставьте 0. Если у Вас не кассовое \ банковское ПО, конечно в) у Вас включен bin log (настроена репликация)? если нет, то убедитесь, что он не включен г) при установленном размере innodb_buffer_pool_size в 1гиг рекомендуется в общем случае использовать innodb_log_file_size = 128m и innodb_log_buffer_size = 32m д) почитайте за возможные значения innodb_flush_method и их отличия. е) зачем трогать довольно тонкие механизмы вроде innodb_max_dirty_pages_pct_* ? из коробки вроде иные значения. оставьте их - дефолтные. ж) mysqltuner говорит что-то внятное?
  10. Сервер я Вам принес, но доступов вам не отдам (с) Рег.ру дичь же
  11. Вам бы озаботиться более насущными проблемами\рекомендациями того же пейджспида: Сократите время ответа сервера (время до получения первого байта). Ведь для большинства страниц сайта у Вас TTFB (время ответа сервера) около 2сек, а иногда и больше. Две драгоценные секунды браузеры клиентов просто ждут ответа и НИЧЕГО не делают. Скорость ответа сервера, как правило, можно здорово уменьшить путем серверных оптимизаций (запросы к базе, кэширование, поиск и устранения разного рода узких мест в настройка\коде и прочее-прочее) Что же касается конкретно Вашего вопроса по скорости выполнения скриптов... как вариант, можете попробовать в скрипте подключения яндекс-метрики отключить какой-нибудь неиспользуемый функционал. Хотя бы тот же веб-визор убрать.
  12. Journal3? Судя по прикрепленному скрину, больше всех жадным до ресурсов оказывается встроенный в тему SuperCache. Кэшировщик. Могу предположить, что у Вас достаточно часто обновляются товары на сайте, из-за чего кэш автоматически полностью очищается и, как результат, возникают всплески нагрузки на работу без кэша\его формирование. Уточните пожалуйста: сколько файлов у Вас в папке кэша? обычно это system/storage/cache (уточню, что в ОС3 папка system скорее всего вынесена за пределы корневой директории сайта - если сразу не найдете). Интересуют файлы, имеющие префикс journal3. как часто обновляются товары? у Вас виртуальный общий хостинг или собственный vps ? какие права стоят на папку с кэшем?
×

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.