MySQL MyISAM + rails tests = bugs

29 апреля 2009, Среда

Пришлось мне на днях потюнить MySQL. Решил попробовать разные конфигурации на предмет максимальной производительности по моим задачам. Нарыл ряд статей по  улучшению производительности. Лучше всего ИМХО написано было сдесь.

Пред история. Сразу скажу что запросы у меня простые и короткие. Пара селектов по индесированым полям + инсерт + апдейт. Ничего сложного. Но! В один прекрасный момент СУБД просто брала и начинала жрать все ресурсы процессора как локально так и на продакшин сервере. Однодневный инвестигейт показал интересную вещь. После инсерта происходит перестрой индексов данной таблицы, что само по себе требует ресурсов процессорного времени и это время прямо пропорционально количеству записей в таблице. Таким образом, если мне нужно много циклов записей/селектов подряд то время каждого цикла начинает расти. И у меня оно дошло до 1го цикла в секунду. Это при том что мне нужно это сделать 300к-500к раз. Посчитав примерно во что мне это обойдется вышло что весь цикл будет длиться с недельку. Это естественно ни в какие рамки не лезет.

Посему начал рыть. Сначала в сторону тюнинга СУБД. В целом добился прироста производительности гдето на 10%. Но проблема как обычно была не в СУБД. Т.е. как-бы в СУБД но не в СУБД. В общем это не самое интересное.

Самое интересно это то, что вовремя тюнинга я настроил все базы на использования движка MyISAM. И тут начались спец-эффекты. Упало ряд тестов. Анализ кода ничего не показал. Анализ фикстур, откаты изменений (я работаю в команде посему начал грешить на последние комиты) все это ни к чему не привело.

Начал думать (гуглом). Как оказалось тесты в рельсах работают (в основном) в режиме транзакций. Т.е. каждый тестовый случаю выполняется как транзакция, которая потом (после выполнения тестового случая) откатывается. Теперь о MyISAM, как извесно этот движек не поддерживает транзакций, поэтому ряд тестов модифицируют данные необратимо. С этим и были связаны глюки. Кроме того, глюки будут также если у вас есть модифицирующие хранимые процедуры.

Вердикт. Для тех кто использует MySQL в тестовых версиях используйте движек InnoDB, иначе могут выпасть очень даже интересные глюки. Или используйте PostgreSQL.

Python+Django+MySQL+Ubuntu 8.10. First step

6 февраля 2009, Пятница

Пишу короткий туториал для того чтобы не забыть.

Для начала поставим python:

sudo apt-get install python

потом поставим django:

sudo apt-get install python-django

Подозреваю что так мы поставим не последнюю версию, а то что доступно в Убунту пакетах. Но пока и этого достаточно.

Создаем тестовое приложение:

python /usr/lib/python-django/django-admin.py startproject testApp

/usr/lib/python-django/ - эту часть ставим у кого куда поставило. В целом нужно в пути добавить чтобы удобней было в будущем.

Далее проверяем что все ок или почти ок:

cd testApp && python manage.py runserver
Validating models...
0 errors found
Django version 1.0-final-SVN-unknown, using settings 'testApp.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Исходя из того что написано делаем вывод что приложение у нас запустилось и работает на 8000 порте.

Идем в браузере - http://localhost:8000/

It worked!

Congratulations on your first Django-powered page.

Of course, you haven’t actually done any work yet. Here’s what to do next:

  • If you plan to use a database, edit
    the DATABASE_* settings in testApp/settings.py.
  • Start your first app by running pythontestApp/manage.py startapp [appname].

You’re seeing this message because you have DEBUG = True in your

Django settings file and you haven’t configured any URLs.
Get to work!

Кажется все работает. Останавливаем сервер.

Теперь подключим  БД. Традиционно буду использовать MySQL 5.x. Для справки, нужно поставить саму СУБД:

sudo apt-get install mysql-server

Теперь нюанс, чтобы django смог работать с MySQL ему нужен python-mysqldb. Ставим:

sudo apt-get install python-mysqldb

Проверяем что у нас все ок:

  • Загружаем интерпритатор python;
  • Пишем import MySQLdb;
  • Если нет исключения значит все ок.

Создаем базу для приложения:

mysqladmin create testApp_development -u root -p

В файле settings.py находим строки:

DATABASE_ENGINE = 'mysql'
DATABASE_NAME = 'testApp_development'
DATABASE_USER = 'db_user_login'
DATABASE_PASSWORD = 'db_user_password'

Где  db_user_login, db_user_password - логин и пароль вашего пользователя в БД соответственно.

Далее инициализируем базу данных для нашего приложения:

python manage.py syncdb
Creating table auth_permission
Creating table auth_group
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
You just installed Django's auth system, which means you don't
have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (Leave blank to use 'billy'): admin
E-mail address: bill.gates@gmail.com
Password:
Password (again):
Superuser created successfully.
Installing index for auth.Permission model
Installing index for auth.Message model

Запускаем опять.

python manage.py runserver
Validating models...
0 errors found

Django version 1.0-final-SVN-unknown, using settings 'testApp.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

В целом это все что касается старта. Пока хватит.




				

Блог работает на WordPress.
Подписка RSS: все записи, комментарии.