Оптимизация работы ZODB

[Loki[FT]]

В данный момент у меня стоит задача поднять портал под plone 3 на
zope2
База уже получилась почти 20G. Тупит местами ужасно.
Немогли бы вы подробнее рассказать как с проблемой разобрались и если
возможно поделиться какми нибудь наработками. (Опыт работы c zope у
меня небольшой а вот зададача оптимизации встала).

Поделитесь мыслями не сей счёт!

[Nikolay Kim]

есть же рассылка по zope2 и plone
http://groups.google.com/group/plone-ru

[ichar]

Нужно понять причину задержек. Для начала открыть debug-лог (уровень
трассировки DEBUG, хотя они есть и на уровне INFO):

файл /etc/zope.conf:

<eventlog>
level ALL
<logfile>
path $INSTANCE/log/event.log
level INFO
</logfile>
<logfile>
path $INSTANCE/log/debug.log
level DEBUG
</logfile>
</eventlog>

Исследовать фактическую работу вашей системы и понять есть ли
ConflictError. Выглядят примерно так:

2008-09-25T10:42:24 INFO ZODB.Conflict database conflict error (oid
0x01c8, class BTrees._OOBTree.OOBTree, serial this txn started with
0x0378c18e17604f44 2008-09-25 06:38:05.478799, serial currently
committed 0x0378c19265cccb22 2008-09-25 06:42:23.859369) at /trading/
storage/SCR/IO/Iskhodjashhie/TDDRNK/200809/0925102733_Siraevu_R_U_/
version/version_0.1/view (3 conflicts, of which 0/0 were unresolved/
resolved, since startup at Wed Sep 24 20:17:51 2008)
------

Класс объекта разумеется может быть любым. Содержание сообщения у вас
может несколько отличаться.

Если конфликты есть: сколько, как часто? Собственно о конфликтах и
речь, они и являются причиной замедлений в работе вашей системы.

Любой конфликт - это повтор транзакции (с самого начала), без разбора,
все заново. Всего 3 попытки. Если ситуация не меняется - Site Error.

Можно еще вот так. Если вы сможете выполнить скрипт (просто "достать"
текущий счетчик конфликтов):

from Zope2.App.startup import conflict_errors

с момента последнего старта вашего приложения. Десятки конфликтов в
день - это плохо, ну а о сотнях и говорить не приходится.

[Сергей Панов]

  Раз у вас Zope я бы вам ОЧЕНЬ советовал поставить deadlock debugger, позволяет в реальном времени отслеживать что выполняет данный поток, сразу увидите на чем имеено тормоза, может и не в конфликтах вовсе дело.

30 октября 2008 г. 14:37 пользователь Loki[FT] <rino...@mail.ru> написал:

--
Best Regards, Panov Sergey

[ichar]

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

Одним словом, я здесь могу что-либо сказать только о конфликтах.

[ichar]

На самом деле можно перехать на Zope2 или Plone (http://
groups.google.com/group/plone-ru), а то тут только людей будет
отвлекать. Что скажут хозяева?

[Mikhail Kashkin]

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

P.S. "хозяева" звучит как-то неприятно

2008/10/30 ichar <Kharl...@tmk-group.com>

На самом деле можно перехать на Zope2 или Plone (http://
groups.google.com/group/plone-ru), а то тут только людей будет
отвлекать. Что скажут хозяева?

--
Mikhail Kashkin

[Loki[FT]]

У меня ещё вознить вопрос наткнулся на компонент RelStorage

Поможет перевод через него mysql скорости работы с базой? Ща в базе
примерно 5 млн записей. Интересно как mysql справиться...

[ichar]

> P.S. "хозяева" звучит как-то неприятно

Критику принимаю.

[ichar]

Не совсем корректно высказанная мысль (или фраза) меня сбивает с
толку. Компоненту RelStorage честно я не встречал. О чем толкуем? Что
за база (sql, zodb) и какую роль она выполняет?

[Nikolay Kim]

> У меня ещё вознить вопрос наткнулся на компонент RelStorage
>
> Поможет перевод через него mysql скорости работы с базой? Ща в базе
> примерно 5 млн записей. Интересно как mysql справиться...

это может помоч если вы используете zeo

[Loki[FT]]

RelStorage - это типа мост между ZODB и реляционными базами наскока я
понимаю. Т.е. реляционная база будет типа хранилищем

[Loki[FT]]

Сейчас у меня база в FileStorage вот я думал мож через RelStorage
перегнать на MySQL. Извиняюсь за некорректно высказанные фразы я в
принципе в плане Zope полный нуб ))

[ichar]

Работать с SQL в питоне и сервере приложений Zope безусловно можно и
нужно, и насколько я понимаю, на западе (продвинутые люди), да и у
нас, так и поступают (когда они говорят "тысяча транзакций в
секунду"). Но вопрос - в каком варианте, зачем, что в SQL хранить и
как его использовать.

Ведь мы понимаем, что внедрением SQL можно просто перечеркнуть все
преимущества динамического контента и собственно Zope. Честно говоря,
некоторое время назад я бы об этом нисколько не пожалел, но вот сейчас
уже жалко и даже совсем не тянет.

Ну куда проще без каких-либо опасений в любой фазе жизненного цикла
ППО в свой код добавить фразу:

self."что-то" = "чему-то" или setattr(self, "идентификатор",
"значение"),

при этом сначала "чему-то" может иметь тип int или еще какой-либо, а
потом DateTimе, а еще позже "бесконечный стринг", и все это будет
работать, и int, и DateTime и т.д., и ровно там где мы это значение
присвоили. Ну разве не роскошь? Ну где вы найдете такой вариант в SQL?
Там поля надо проектировать, тщательно, и с прицелом на будущее.

Это только один из эффектов. Ведь "что-то", как член класса, может
быть не только атрибутом, но и методом. Во где дела! Например, в Zope
можно принципиально изменить работу готового приложения, не внося ни
строчки нового кода, без единой правки текстов программ, размещенных в
файловой системе.

Или еще, всякие "триггера" (образно говоря). Можно всегда
переопределить любой член, любой метод, любой класс. Правда, с
последним persistent есть некоторые неувязки (или этот злополучный
BTrees).

Т.е., думаю, что часть данных целесообразно вынести в SQL (например,
индексы, или статистику посещений и что-либо подобное "недорогое" или
"восстанавливаемое"), а часть (первоисточник) оставить все-таки на
месте.

RelStorage не видел, но есть и другие продукты. Например, для MySQL
достаточно поддержки под питон (MySQL-python, существует, как всегда,
множество версий) и продукт под названием ZMySQLDA, и все это всегда
можно подготовить (оптимизировать) под свои
цели. Лично я так и поступил.

Есть ZSQLMethods.

Правда, все это в варианте Zope2, Zope3 не использую. Но
принципиальной разницы, думаю, нет. Да, нотации другие, интерфейсов
больше, но ZODB (пиклизация, сериализация и др.свойства) одна, и
никуда не денется. + конечно же, Python со всеми замечательными
задумками Гвидо ван Россум.

Правда, за все надо платить, как водится. Надо "копать", и порой
немало.

[Cykooz]

On 9 нояб, 14:15, "Loki[FT]" <rino_m...@mail.ru> wrote:

> Ща в базе
> примерно 5 млн записей. Интересно как mysql справиться...

А какого плана эти самые 5 милионов объектов? Насколько они большие?
Ведь по умолчанию zope кэширует 20000 объектов из ZODB, вы не
проверяли сколько оперативной памяти занимает процес zope?

У меня zope2 страшно начинал тупить, когда instance очень сильно
раздувался. А так как таких инстанцев было штуки 6, и каждый занимал
400-800 метров оперативы, то видимых серваку 3.5 Гб оперативы не
хватало и начинался зверский свопинг. Я решил эту проблему объеденив
все инстанцы в один, он конечно стал раздуваться до 1 Гб и работать не
так быстро как по отдельности, но это гораздо лучше чем 6*700 Мб и
жуткие тормоза всего сервака.

PS: меня вообще пугает zope именно своей прожорливостью, и как при
этом скажите на милость организовать на одном сервере несколько
сайтов?

PPS: RelStorage я пробывал, и он мог бы вам помочь если дело в
конфликтах при работе ZODB. Как отмечает сам автор - RelStorage
существенне быстрее FileStorage, особенно при большом количестве
конкурентных запросов. А в целом это то же ZODB только хранящийся не в
файловой системе, а в базе данных. Кстати по моему личному мнению
RelStorage гораздо удобнее использовать, чем ZEO.

[ichar]

> > Ща в базе
> > примерно 5 млн записей. Интересно как mysql справиться...
>
> А какого плана эти самые 5 милионов объектов? Насколько они большие?
> Ведь по умолчанию zope кэширует 20000 объектов из ZODB, вы не
> проверяли сколько оперативной памяти занимает процес zope?

Предполагаю, что эти 5 млн в основном экземпляры brains каталога (тот
самый BTrees):

Products/ZCatalog/Catalog.py:

self.data = IOBTree() # mapping of rid to meta_data
self.uids = OIBTree() # mapping of uid to rid
self.paths = IOBTree() # mapping of rid to uid
self._length = BTrees.Length.Length()

У меня была аналогичная ситуация, и сервер тупил страшно, все то же.
Как только убрал каталог (перевел в SQL) объектов стало 500 тыс
(примерно на порядок меньше) и "дело пошло" )).

Кэшем в принципе можно управлять, но если пользователей и запросов
много, расти все равно будет (здесь до конца не понимаю как повлиять):

etc/zope.conf:

<zodb_db main>
# Main FileStorage database
cache-size 40000
pool-size 15
<filestorage>
path $INSTANCE/var/Data.fs
</filestorage>
mount-point /
</zodb_db>

можно еще поиграться с Advanced закладочкой каталога (параметр "Set
Subtransactions Threshold", но особого эффекта не даст).

Правильно, конечно, автору уточнить природу этих 5 млн.