we are sorry, we are open

Правда купил я его уже давно – 10.06.2010 – но из-за серьёзных событий в стране никак не доходили руки написать свой обор. Хватило только на краткий обзорчик «Свершилось наконец-то – купил я себе новый коммуникатор )», который был написан 29 июня 2010 г. Вот его я и дублирую здесь, всё-таки тут у меня домашняя страница )
(продолжение…)

Я не такой уж и большой специалист по MySQL, так что приведённые далее наблюдения прошу не считать показательными – это просто мои эксперименты на моём сервере и с моей БД )

Озаботился проблемой разрастания таблиц в БД. Надо их дефрагментировать. Таблицы в InnoDB. Провёл пару замеров с одной из самых больших таблицей под рукой – log:
- больше 3 миллионов записей;
- размер файла log.ibd – 3,5ГБ;

Для начала мне нужно было заменить значение одного из полей таблицы:
mysql> update log set tip='no data';
До замены в этом поле была довольно длинная строка с информацией user-agent, полученной от браузеров, посетителей, т.е. новая строка в несколько раз короче старой.
Результаты:
Query OK, 3033596 rows affected (57 min 56.91 sec)
Rows matched: 3239214 Changed: 3033596 Warnings: 0
Размер файла заметно увеличился – 4ГБ. Очевидно надо дефрагментировать таблицу (это был плавный переход к следующему тесту)))

Второй тест – оптимизация таблицы:
mysql> optimize table log;
Результаты:
mydb.log | optimize | note | Table does not support optimize, doing recreate + analyze instead
mydb.log | optimize | status | OK
2 rows in set (38 min 47.55 sec)
Размер файла существенно уменьшился – 2,7ГБ, а было ведь 4ГБ!
Напрашивается вывод о том, что оптимизацию надо проводить почаще, но тут надо учитывать, что во время оптимизации таблица будет заблокирована и недоступна для ваших скриптов.

Для полноты картины конечно не обойтись без информации о сервере – старенькая рабочая станция:
- софт – FreeBSD 7.2, apache 2, php, MySQL;
- Intel Pentium4 3.40GHz;
- RAM 3GB;
- система и БД лежат на двух разных винтах;
- сервер, фактически, выделенный;

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

Дополнение от 03-08-2010

Добавление индекса к база размером более 4ГБ и с более 4 с половиной мульёна строк заняло 18 минут полного отказа СУБД от обслуживания:
mysql> alter table log add index (id_site);
Query OK, 4784444 rows affected (18 min 49.74 sec)
Records: 4784444 Duplicates: 0 Warnings: 0

test
test

Дополнение:
Сделал тестовую запись, а удалять стало жалко – фотка красивая. Пускай остаётся )))
На фотке мотоцикл Урал.

Выкладывают работы местной тату-мастерицы Натальи. Знаю её лично, но не как тату-мастера – серьёзная, отвественная, к тому же сипатичная )
К сожалению я не знаю её квалификацию, где обучалась, не знаю какими красками и какой машинкой пользуется.
Контактные данные:
- телефон рабочий: 67-82-95
- телефон мобильный: 0 772 37-30-67
Рабочие дни: вторник, четверг, суббота, воскресенье.

По катом галерея работ Натальи.
(продолжение…)

Задают вопросы о трафике и нагрузке на сервер форума diesel.elcat.kg в кризисные дни очередной революции. Многие интересуются из чистого любопытства, но некоторые в академических целях, например айтишники.
(продолжение…)