"Блокировка" магазина при выполнении обработок

[alexts 18]

При закачке из экселя, нарезке картинок магазин становится полностью недоступен для посетителей.

Хочется понять :

Это связано с возможностями MySql

Потому, что так написан код скриптов,

Еще какие причины ?

Почему ресурсы свободные есть, а он блокируется, и как распараллелить выполнение задач?

[support 447]

Ну если большая слишком нагрузка на базу, то да, может быть недоступен.

 

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

 

Может нарезка картинок всё тормозит, это довольно ресурсоёмкая задача.

[alexts 18]

Не , обновляется прайс - в магазин не войдешь.

Нарезка - так вообще операция таинственная. К базе вроде совсем отношения не имеет.

А выставить лимиты потребления для скриптов никак нельзя? Пусть дольше, зато доступ останется...

[support 447]

Не знаю, вроде нет.

[alexts 18]

А про использование storage engine innodb , а не myisam ничего не скажете.

В битриксе, в статье по оптимизации mysql под эту прожорливую систему, акцентируют именно на innodb.

Или я что то не понимаю.

Но вот на серваке установлено как дефолт innodb. Смотрю в phpmyadmin базу магазина - таблицы myisam.

Может надо(или не надо) пересоздавать, конвертировать... Или фигней занимаюсь ? :)

[support 447]

Лично я считаю, что движок не принципиален, если у Вас не миллионы записей в базе, нет каких супер сложных sql запросов.

 

Разве что у myisam бывают проблемы, даже на форуме не раз и не два писали о том, что у пользователей таблицы ломались (crashed) и приходилось их восстанавливать (repair).

 

Но это тоже редкость и легко исправляется.

 

В общем, пусть что есть, то и остаётся.

 

P.S. Кстати, тоже интересна была эта тема, много есть статец на этот счёт в инете, там описаны все детали, в чём разница. В VamShop 2 используется именно InnoDB, но разницы, видимой глазу, всё равно нет, разве что я пока что не видел, что б у InnoDB таблицы ломались как у Myisam. Так что для большинства случаев движок не важен. 

[alexts 18]

Приблизился к просветлению.

Самое важная разница в обсуждаемом контексте (для нашего уровня задач) то, что в innodb блокировка на уровне полей, в майсам на уровне таблиц. То есть во втором случае при записи в базу блокируется и эта таблица и все связанные.

Что еще понял - таблицы обоих типов могут существовать одновременно.

Майсама критично быстрее на выборках и поддерживает полнотекстовой поиск, но блокирует таблицами

Innodb - самовосстановима, поддерживает целостность транзакций, блокировка на уровне полей - то есть реально распарраллеливает нагрузку.

Самое главное - поддерживается то, что написал программист :(

Вывод: никак распараллелить операции без переписки кода магазина не получится :(

Вывод 2: блокировка магазина при загрузке и обновлении прайса из экселя - естественное явление , обусловленное использованием таблиц myisam.

Вывод 3: - хреново, поскольку виден "потолок" масштабирования движка и неожиданно не в количестве и объемах, а в обеспечении непрерывной доступности :(

[support 447]

В таких тонкостях пока не разбирался, да и не проблема ведь поменять движок таблиц, сделать backup, да поменять MYISAM на INNODB и KEY на INDEX

[alexts 18]

А как это "не проблема" реально сделать? В каком конкретно месте? Я бы поэкспериментировал , возможно можно избавиться от вышеперечисленных блокировок

[support 447]

В sql файле, т.е. в дампе базы данных внизу каждой таблицы указывается движок. 

[alexts 18]

Спасибо. Сейчас одно дельце сделаю и поиграюсь. Отпишусь по результатам.

[support 447]

Хорошо

[alexts 18]

В общем попробовал.

Переименование MYISAM на INNODB позволило переключить движок - работает вроде без глюков и в логах и в phpmyadmin порядокю

Переименование KEY на INDEX - сбой при загрузке еще первой таблицы - не делалось.

Теперь о результатах - нулевые , как блокировался магаз при выполнении скриптов нарезки и загрузки , так и остается недоступным.

Видимо скрипты покруче будут , чем какой то INNODB. Им пофигу уровни блокировок на уровне полей - используют захват на полную катушку даже не таблицами, а сразу всю базу :)

 

Таким образом, смысл перехода на данный движок в следующем:

1. Для растущих и разросшихся баз

2. Чтобы не опитмизировать таблицы - здесь это не надо

3. Движок поддерживает целостность транзакций и такую базу труднее "убить".

Кстати по производительности отличий не замечено, но это субъективно - глубоко не копал и не грузил.

В общем просветился, а задачу блокировок так и не решил :(

 

Разумеется - грубый метод. Подозреваю, что разработчик должен грамотно назначить какие таблицы в каком режиме лучше будут работать. Может это и позволило бы развести скрипты и посетителей ...