Jump to content
mobiopt

Сайт умирает при выгрузке товара из 1С, нужна помощь

Recommended Posts

Выгружаем товары (11000 штук) из 1С на сайт с помощью дополнения "NeoSeo Обмен с 1C", если запустить выгрузку 2 раза в течение получаса, то сайт становится не доступен минут на 10.

Проблема с хостингом?

Share this post


Link to post
Share on other sites

с нехваткой ресурсов

 

ну или в модуль вшили тормоза чтоб за доработку денег брать

Share this post


Link to post
Share on other sites

возможно у вас что то начинает генерироваться... превью фоток например... чаще это сжирает много ресурсов

Share this post


Link to post
Share on other sites
12 minutes ago, Otvet said:

с нехваткой ресурсов

ресурсов чего? просто понять бы к кому обращаться

Share this post


Link to post
Share on other sites
10 минут назад, Tobolskiy сказал:

превью фоток например... чаще это сжирает много ресурсов

У меня есть замечательный модуль для предгенерации превью фоток - пишите в лс за ссылкой.

Share this post


Link to post
Share on other sites
8 часов назад, mobiopt сказал:

ресурсов чего? просто понять бы к кому обращаться

Надо в момент когда сайт становится недоступным посмотреть состояние веб-сервера, базы. Для начала веб-сервер можно промониторить например через консоль, командой top, для подробностей что смотреть надо погуглить на эту тему. Базу можно посмотреть запросом SHOW FULL PROCESSLIST, много ли запросов в момент зависания и может какие-то запросы зависли.

Ну а дальше уже более подробно надо разбиратся, например видим из top, что процессор загружен, смотрим там же какими процессами. А если видим в базе висящий запрос/запросы, то начинаем разбиратся почему они висят.

Я делаю ставку на то, что будет обнаружены висящие запросы в базе )

Share this post


Link to post
Share on other sites
9 часов назад, mobiopt сказал:

Выгружаем товары (11000 штук) из 1С на сайт с помощью дополнения "NeoSeo Обмен с 1C", если запустить выгрузку 2 раза в течение получаса, то сайт становится не доступен минут на 10.

Проблема с хостингом?

11000 товаров - если на добавление товара, то  по 20+ запросов к БД на каждый товар, итого будет 220000+  запросов примерно.

То есть 10 минут при минимальной конфигурации БД это нормально.

Если хотите что бы "залетало" за минуту - увеличивайте ресурсы БД + тюнинг конфига, для MySQL предела нет по памяти (RAM), сколько не корми ;)

Либо смотреть в сторону PostgreSQL.

 

Share this post


Link to post
Share on other sites
48 минут назад, costas сказал:

11000 товаров - если на добавление товара, то  по 20+ запросов к БД на каждый товар, итого будет 220000+  запросов примерно

Почему именно такое кол-во запросов, алгоритм же можно поразному написать.

49 минут назад, costas сказал:

Либо смотреть в сторону PostgreSQL

А какие плюсы у Posgresql в этом плане перед Mysql, кол-во запросо то остатеся же тем же?

Share this post


Link to post
Share on other sites
11 минут назад, i3bepb сказал:

Почему именно такое кол-во запросов, алгоритм же можно поразному написать.

Алгоритм не влияет на инсерты в таблицы, от перестановки слагаемых сумма не меняется.

Нельзя из двух инсертов в две таблицы, сделать один в те же две таблицы.

13 минут назад, i3bepb сказал:

А какие плюсы у Posgresql в этом плане перед Mysql, кол-во запросо то остатеся же тем же?

гугл в помощь.

Share this post


Link to post
Share on other sites
1 минуту назад, costas сказал:

Алгоритм не влияет на инсерты в таблицы, от перестановки слагаемых сумма не меняется.

Нельзя из двух инсертов в две таблицы, сделать один в те же две таблицы.

Например есть 100 товаров и 2 таблицы, можно на каждый товар делать 2 запроса и получить 100*2=200 запросов, а можно использовать bulk insert и вставить сразу все 100 товаров сначала в одну таблицу, затем во вторую и получить 2 запроса, по запросу на таблицу. Поэтому и пишу, что алгоритм может быть разным

 

7 минут назад, costas сказал:

гугл в помощь.

Зря Вы так, очевидно же если бы в Postgresql запросы SELECT или INSERT делались в разы быстрее, то Posgresql бы убил Mysql. А так это только рождает мифи о том, что вот если бы использовать Postgresql, то не было бы проблем. Postgresql не лучше, не хуже Mysql это просто другая система и все, в которой есть свои плюсы, минусы. Вы даже не знаете какой алгоритм в обновлении товаров, т.е. Вы не знаете какая там проблема и советуете на неизвестную проблему решение - Posеgresql. Хорошо наверное Вы держите в голове какую-то определенную проблему, которую помогает решить Postgresql, когда предлагаете решение. Вы предположили 220000+ запросов, ок, тогда я задал вопрос как Postgresql поможет решить эту проблему, а Вы посылаете в гугл, закрадывается мнение, что Вы и сами не знаете чем поможет Postgresql.

Share this post


Link to post
Share on other sites
1 час назад, i3bepb сказал:

Например есть 100 товаров и 2 таблицы, можно на каждый товар делать 2 запроса и получить 100*2=200 запросов, а можно использовать bulk insert и вставить сразу все 100 товаров сначала в одну таблицу, затем во вторую и получить 2 запроса, по запросу на таблицу. Поэтому и пишу, что алгоритм может быть разным

Полагать, что один запрос который содержит все в одной строке все 100 запросов, будет как то другому обрабатываться архитектурой MySQL и будет работать быстрее - это даже не близко к Junior Database Administrator... без комментариев

 

1 час назад, i3bepb сказал:

Зря Вы так, очевидно же если бы в Postgresql запросы SELECT или INSERT делались в разы быстрее, то Posgresql бы убил Mysql. А так это только рождает мифи о том, что вот если бы использовать Postgresql, то не было бы проблем. Postgresql не лучше, не хуже Mysql это просто другая система и все, в которой есть свои плюсы, минусы. Вы даже не знаете какой алгоритм в обновлении товаров, т.е. Вы не знаете какая там проблема и советуете на неизвестную проблему решение - Posеgresql. Хорошо наверное Вы держите в голове какую-то определенную проблему, которую помогает решить Postgresql, когда предлагаете решение. Вы предположили 220000+ запросов, ок, тогда я задал вопрос как Postgresql поможет решить эту проблему, а Вы посылаете в гугл, закрадывается мнение, что Вы и сами не знаете чем поможет Postgresql.

Исходя из выше сказанного:

В гугл и еще раз в гугл.

Share this post


Link to post
Share on other sites
34 минуты назад, costas сказал:

Полагать, что один запрос который содержит все в одной строке все 100 запросов, будет как то другому обрабатываться архитектурой MySQL и будет работать быстрее - это даже не близко к Junior Database Administrator... без комментариев

Правильно говорит не "все 100 запросов", а все 100 товаров. Вам наверное не знаком термин bulk insert и Вы не понимаете о чем Я написал. Посылаю Вас в гугл по фразе "mysql bulk insert". Да такой один запрос будет обрабатыватся архитектурой mysql по другому, нежели 100 отдельных - для mysql такой запрос пойдет одной транзакцией, а это значит данные на жесткий диск он скинет тоже за раз, а не будет их скидывать 100 раз, также ему надо будет перестроить индексы при появлении новой записи в таблице, это он сделает тоже один раз, а не после каждого запроса на товар. В итоге мы получаем более оптимальную работу с жестким диском и операция перестроения индексов происходит 1 раз, а 100.

 

46 минут назад, costas сказал:

Исходя из выше сказанного:

В гугл и еще раз в гугл.

Это просто возмутительно! )))

Share this post


Link to post
Share on other sites
5 минут назад, i3bepb сказал:

Правильно говорит не "все 100 запросов", а все 100 товаров. Вам наверное не знаком термин bulk insert и Вы не понимаете о чем Я написал. Посылаю Вас в гугл по фразе "mysql bulk insert". Да такой один запрос будет обрабатыватся архитектурой mysql по другому, нежели 100 отдельных - для mysql такой запрос пойдет одной транзакцией, а это значит данные на жесткий диск он скинет тоже за раз, а не будет их скидывать 100 раз, также ему надо будет перестроить индексы при появлении новой записи в таблице, это он сделает тоже один раз, а не после каждого запроса на товар. В итоге мы получаем более оптимальную работу с жестким диском и операция перестроения индексов происходит 1 раз, а 100.

 

Это касается одной таблицы oc_product, это всего один запрос к БД из 20+, после этого запроса потом нужно будет делать поиск product_id что бы продолжить инсерты в связанные таблицы со всеми вытекающими.

 

Хотя..., можно же загрузить все тысячи полученных product_id после mysql bulk insert в память, потом спарсить в новые инсерты сделанные по шаблону и сного толкнуть это в виде mysql bulk insert  по связанным таблицам и молиться, что данные попадут куда надо... забыли про обновление товаров, но оно и не надо... ключевое слово в этой оптимизации  "молиться"...

 

В итоге  mysql bulk insert никаким образом в реале не применимы, кроме как дампы, бэкапы и миграции.

Share this post


Link to post
Share on other sites
1 час назад, i3bepb сказал:

Правильно говорит не "все 100 запросов", а все 100 товаров. Вам наверное не знаком термин bulk insert и Вы не понимаете о чем Я написал. Посылаю Вас в гугл по фразе "mysql bulk insert". Да такой один запрос будет обрабатыватся архитектурой mysql по другому, нежели 100 отдельных - для mysql такой запрос пойдет одной транзакцией, а это значит данные на жесткий диск он скинет тоже за раз, а не будет их скидывать 100 раз, также ему надо будет перестроить индексы при появлении новой записи в таблице, это он сделает тоже один раз, а не после каждого запроса на товар. В итоге мы получаем более оптимальную работу с жестким диском и операция перестроения индексов происходит 1 раз, а 100.

 

Это просто возмутительно! )))

 

Замечательные специалисты.

 

Правды нет ни в одном ни во втором утверждении. Все зависит от структуры таблицы и количества индексов, и даже иногда, как это странно не будет звучать от того что у вас mariadb или mysql.

На нагруженных проектах как одна из мер решить вопрос быстрого апдейта - это отключение/включение механзима индексов на время импорта.

 

Что касается вопроса ТСа - то проблемы могут быть в чем угодно.
В отсутсвии индексов, в некорректной конфигурации mysql сервера, в нехватке ресурса процессора, в плохом коде (откуда правда там взяться хорошему). И эти проблемы существуют почти у всех. Так как разработчик не тестируют свои решения на большом объеме данных. На демо заработало и ок.


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

 

 

Share this post


Link to post
Share on other sites
1 час назад, snastik сказал:

В любом случае любую проблему необходимо первично диагностировать. А в данном случае все советы сводятся к попыткам тыкнуть пальцем в небо.

Золотые слова, я потому с этого и начинал:

 

7 часов назад, i3bepb сказал:

Надо в момент когда сайт становится недоступным посмотреть состояние веб-сервера, базы. Для начала веб-сервер можно промониторить например через консоль, командой top, для подробностей что смотреть надо погуглить на эту тему. Базу можно посмотреть запросом SHOW FULL PROCESSLIST, много ли запросов в момент зависания и может какие-то запросы зависли.

Ну а дальше уже более подробно надо разбиратся, например видим из top, что процессор загружен, смотрим там же какими процессами. А если видим в базе висящий запрос/запросы, то начинаем разбиратся почему они висят.

Я делаю ставку на то, что будет обнаружены висящие запросы в базе )

 

Это уже потом мы с @costas начали писюнами мерится, после того как он пальцем в небо тыкнул.

Share this post


Link to post
Share on other sites
16 часов назад, i3bepb сказал:

Золотые слова, я потому с этого и начинал:

 

 

Это уже потом мы с @costas начали писюнами мерится, после того как он пальцем в небо тыкнул.

 

От того что вы меряетесь, кроме флуда, ТС не получил никакой полезной информации.

А вот методология ваша не очень, потому что никакой top не покажет вам к примеру такое:


Если я правильно понимаю импорт 1с это форк от @kirilove. И насколько я помню, он использует стандартные методы движка для обновления товаров. И предположим, у него есть дописка, которая сбрасывает кеш сеопро при каждом обновлении товаров, а на фронт при этом идет трафик, который судорожно пытается его сгенерить.

Скажите, какой top его покажет ?

 

Или второй пример. Предположим что там таблицы myisam - ну там это на 99%.
В процессе обмена, естественно становятся все таблицы oc_product_*, и ложится весь магазин, а никто не отменял трафик из мира, и что мы получаем? Экспоненциальный всплеск нагрузки из-за заблокированных таблиц! Но если мы попытаемся сделать explain у тех же запросов, которые допустим, увидим как медленные в логе медленных запросов или в mytop - мы не увидим какой-то проблемы.

Share this post


Link to post
Share on other sites
Posted (edited)
34 минуты назад, snastik сказал:

Или второй пример. Предположим что там таблицы myisam - ну там это на 99%.
В процессе обмена, естественно становятся все таблицы oc_product_*, и ложится весь магазин, а никто не отменял трафик из мира, и что мы получаем? Экспоненциальный всплеск нагрузки из-за заблокированных таблиц! Но если мы попытаемся сделать explain у тех же запросов, которые допустим, увидим как медленные в логе медленных запросов или в mytop - мы не увидим какой-то проблемы.

 

17 часов назад, i3bepb сказал:

SHOW FULL PROCESSLIST

Если выполнить в момент тормозов покажет эти запросы с большим временем выполнения. Т.е. будет видно прямо какой запрос висит и уже потом разбираться почему он висит. Я же писал наиболее простые действия, возможно которые ТС сможет выполнить самостоятельно и затем дать больше информации о проблеме. А top он даже ситуацию с зависшими запросами отразит. Пример - таблица с товарами заблокировалась, запросы встают в очередь, mysql начинает жрать все больше ресурсов - память, процессор и в top процесс mysql выходит в топ )))

 

@snastik Вы тоже не правы, ТС спросил куда копать - веб-сервер создает нагрузку при создании кэша или в БД какая-то проблема и как раз top даст первоначальное направление. А Вы уже начали писать предположение, что это создание кэша или тип таблицы там myisam вдаваться в тонкости, как это поможет ответить на вопрос ТС:

В 08.05.2020 в 00:56, mobiopt сказал:

ресурсов чего? просто понять бы к кому обращаться

Edited by i3bepb

Share this post


Link to post
Share on other sites
Цитата

SHOW FULL PROCESSLIST

 

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

 

37 минут назад, i3bepb сказал:

@snastik Вы тоже не правы, ТС спросил куда копать - веб-сервер создает нагрузку при создании кэша или в БД какая-то проблема и как раз top даст первоначальное направление. А Вы уже начали писать предположение, что это создание кэша или тип таблицы там myisam вдаваться в тонкости, как это поможет ответить на вопрос ТС:

 

В каком месте я не прав, и где вы увидели предположение, я просто вам смоделировал пару ситуаций, которые выходят за рамки ваших методов. В отличии от вас с костасом, я не пытаюсь ни с кем меряться, а объясняю, что существуют ситуации, в которых все ваши предложения в целом абсолютно бесполезны. Тем самым подчеркивая, что не стоит тыкать пальцем в небо, для того чтобы просто оставить комментарий под постом про проблемы у ТС.

 

Share this post


Link to post
Share on other sites
9 часов назад, snastik сказал:

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

 

10 часов назад, i3bepb сказал:

Если выполнить в момент тормозов

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
You are posting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×

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.