Итак, ТраффПро протрудился честно на моём сервере буквально пару недель. За это время его таблица в базе весит уже не много ни мало 612 МБ! Это далеко не есть гут. График текущей нагрузки строится минуты 2. Остальные отчёты не меньше. Отсюда решил проанализировать таблицу и нашёл вот что.

Итак, самы больше url_usr_serfing и clients_traff. Собственно по ним.

1. Поле id_client типа bigint. Это у кого же интересно столько клиентов будет? Даже самые извращенцы - разработчики БД больше чем 4-байтовый integer не используют. Ну куда вам столько, вы скажите? Кроме того, теория говорит, что SQL-сервера гораздо быстрее обрабатывают типы int, нежели bigint.

2. Поле порт типа int. Теория говорит, что максимальный номер порта может быть 65535, что есть два байта, или word, но никак не 4.

3. Поля tr_int, tr_out - аналогично. В int поместится 4 GB - куда больше?

4. Поле size из url_usr_serfing - аналогично.

 

А теперь посчитаем, сколько мы могли бы сэкономить.

1. Таблица clients_traff. Сейчас у меня весит 234 МБ. При использовании моего предложения мы экономим по 14 байт на запись. Всего записей 1891288, умножаем на 14 получаем 26 МБ экономии. Плюс уличшенная производительность при использовании типа int вместо bigint.

2. Таблица url_usr_serfing. Сейчас 379 МБ. Экономия 10 байт на запись. Всего записей 3317065, умноаем на 10 получаем 33 МБ экономии и то же улучшение произвоительности.

Вообще, я никого не укоряю, просто не всегда сразу видны изъяны при разработке, которые называются избыточностью БД и она без проблем устраняется впоследствии при эксплуатации. Вот вам и пища для размышлений. Мою таблицу в 612 МБ можно урезать на 60 МБ, что составляет 10% ;)

Ждем ответа Sly, мой размер базы в дампе 2-га И это очень много

Но эксперементы с БД, это очень так сказать серьезно, мне не знать так как я с начала проекта столько крахов видел. Только бэкапы и спасают. Вчера это еще раз в спомнил при обновлении траффпро, база не хорошо обновилась.

Да, есть такое, давно хочу сделать небольшую ревизию хозяйства БД, но всё что то ни как до неё не доберусь

У меня поэтому раз в сутки бэкап делается :)

Сейчас вот проведу локально для себя оптимизацию - посмотрю сколько реально экономия получается. Пока переконвертировал поле port с int на unsigned small - таблица уменьшилась с 234 до 222 МБ. Буду дальше пробывать. Если нужно будет, могу потом пустой дамп со структурой скинуть.

 

Закончил только что перетряску БД. Реальное уменьшение размера практически совпало с расчётным - с 620 МБ вся база уменьшилась до 533 МБ. И даже небольшой прирост заметен при построении веб-админкой графика текущей нагрузки. Правда всё-равно долговато. Сейчас попробую поковырять скрипты самой веб-админки.

Для оптимизации базы объдените поля dates times в таблице clients_traff  оставив только поле times в формате time() о начале эры unux. это поможет намного быстрее открывать графики!  всего 19,493,496 записей с текущей ситуацией график отрываеться 32 секунды. если правильно выставить типы данных и сократить количество полей то будет намного быстрее.

По быстродействиюв баг-трекинге есть записи. Там же есть варианты ускорения. Например у меня с таблицей в пару гиг графики в цвеб-админке строятся от 2 до 15 секунд - все зависит от текущего дня в месяце :)

 

Вот ссылка: http://www.bugtrack.upit-systems.com/view.php?id=16

P.S. Нужно будет зарегаться в баг-трекинге, но это не проблема :)

Читайте настройка mysql
И скоро выйдет версия с оптимизацией БД. Вот только в какую версии будет поставка пока не известно.

Подскажите, а как обнулить таблицу, то есть оставить список групп, пользователей и лимитов без выкаченного траффика за все предъидущие периоды

dispatcher, очисти самые большие таблицы в мускуле (clients_traff и, если включена запись адресов, url_usr_serfing)

larry спасибо