|
02.08.09 18:38 |
Die Katze   | Я влипла... |
ru |
Очень серьёзно...
|
| Comments: 20 | |
| |
|
|
| updated 02.08.09 19:00 02.08.09 18:10 |
kirillica | MySQL: MyISAM vs InnoDB vs MEMORY |
ru |
Те, кто играют в Двар, знают, что на сайте у тамошних Мерков есть мега-ресурс - рейтинг игроков. "Мега" он и по посещаемости, и по экспонентальным формулам рассчета очков рейтинга. Когда появилась первая версия ресурса, в базе было коло 30000 игроков. Исторические сложилось, что движки обоих таблиц, используемых в рейтинге - MyISAM. Вроде бы, "родной" движок от самих разработчиков MySQL, да и (с такими-то объемами) все работало "на ура". Тем более, что MyISAM позиционируется MySQL как лучший для OLAP (On-line Analyze Processing).
Но время идет, рейтинг дополняется новыми категориями, количество игроков в базе растет, и вот теперь это уже более 180 000 записей и более 500 select/insert/update/delete'ов по первичному ключу в минуту. И это без того самого пресловутого OLAP, который (в нашем случае) и есть выдача рейтинга по заданным пользователем критериям. Путем экспериментов, нашел комбинацию запросов, которые позволяю сделать это максимально быстро:
1) SELECT count(*) FROM <tables> WHERE <user filter> - дабы узнать, сколько же пользователей удовлетворяет фильтру
2) SELECT <data> FROM <tables> WHERE <user filter> LIMIT <page> - непосредственно страница рейтинга
3) SELECT count(*) FROM <tables> WHERE rating > <data entry rating> UNION ... - запрос UNION с для определения позиции каждого игрока на странице (это нужно потому, как сортировки бывают не только по рейтингу, поэтому лучший в одной категории может быть худшим в общем зачете, что и надо бы отразить его местом). Т.е. 3 запроса на каждую отображаемую страницу.
Все работает более-менее, пока пользователь захочет посмотреть не первую страницу, а, скажем 3001-ую. Что важно: на каждое поле, на которое может быть наложена сортировка и/или поиск - стоит индекс. Выходит, 12-20 секунд (в зависимости от загруженности сервера) - это предел производительности. Более того, фактически все это время таблицы залочены, а это значит, что остальные запросы ждут, пока выполнятся эти, при этом количество тредов в статусе Waiting резко возрастает. Быстрее MyISAM просто не может (железо хорошее, под базу выдано прилично ресурсов). А что сделает пользователь, когда он пару раз подождет? Правильно, среднестатистический серфер предпочтет вообще больше не ждать. Значит, надо что-то делать.
Иду в гугл, думаю. Ага, InnoDB - чуть-чуть хуже для OLAP (вроде как), но заметно лучше при таком количестве транзакций. И написано красиво: поменяйте движок через ALTER TABLE <table> ENGINE = InnoDB; - и будет вам счастье. Смотрю на загрузку сервера. Вроде, никого нет (времени - первый час ночи), тестирую производительность по транзакциям на локальной машине - действительно лучше. где-то на 10%. Запускаю. Ага... На 15ой минуте мне больше ничего не оставалось, как убить процесс. Сервер встал, загрузка выросла с 0.7 до 2.5, количество процессов в очереди поражает воображение. Но вот что интересно: KILL <process id> в MySQL процесс-то убило, он перешел в статус End, но сервер "не отпустило" и локи с таблиц не сняло. подождал пару минут и сделал в консоли "красивый" стоп-старт: /etc/init.d/mysqld stop. И что вы думали? Не останавливается. Говорит, failed - и все. Остается крайняя мера - kill -9 <pid>. Убился. Поднялся. Думаю дальше.
Делаю новый скрипт: создаю еще одну табличку, но уже с правильным движком, запускаю INSERT INTO ... SELECT * FROM - и жду. На этот раз 11 минут. И 10 минут на OPTIMIZE (на всякий случай), ибо "вес" таблицы вырос с 130 до 160 мегабайт. Последнее не помогло. Добавляю ссылку одной таблицы на другую, что бы совсем красиво и совсем как в крутых RDBMS (Relational DataBase Management System): CONSTRAINT FOREIGN KEY. Проверяю активно вывод рейтинга. И расстраиваюсь в конец. Предыдущие 12 секунд стали 2 минутами 12 секундами. Ладно, думаю, индексы не пересчитал (на сайте произовидтеля пишут, что такая бага иногда бывает, хотя... чего это он делал там 11 минут?). Делаю DROP ... CREATE INDEX... , как умные люди советуют. Не помогает. В шоке. Называется, починил рейтинг. Зато обычные транзакции просто летают.
И тут меня осенило. Памяти на сервере дофига, а что, если сделать систему с двумя таблицами на базе InnoDB и MEMORY. Т.е. для вывода рейтинга просто запихнуть все в HEAP, т.е. в память. В свое время ребята из Oracle рассказывали, что так их клиенты решают свои проблемы с производительностью. Остается надеется, что ребята из MySQL, т.е. из Sun Microsystems, т.е. из IBM, который, в свою очередь, выпускает мало кому нужную, но по слухам крутую DB2, ничуть не хуже.
Читаю мануал, интересные вещи пишут. В MySQL (по умолчанию) данный движок юзают для небольших таблиц, записи в которых не очень-то и важны. Например, список сессий. Если сервер перезапусткается/умирает - данные пропадают, но структура остается. Но мне так и так раз в 10 минут надо перезаписывать данные там, так что подходит. Эту задачу решим с помощью crontab. А что делать с объемом данных? Ага, пишут: измените в системных настройках max_heap_table_size - и солнышко засветит даже в полтретьего ночи. Увеличиваю, создаю структуру таблицы (внимание, MEMORY поддерживает HASH-индексы, но их надо определять вручную через USING HASH, поэтому тупо копировать структуру для лучшей скорости просто глупо. об этом, кстати, пишут вообще где-то в темных уголках мелкими буквами. это, кстати, первые грабли, которые надо знать).
Копирую через INSERT INTO ... SELECT * FROM - через 4 секунды "вылетает" с ошибкой, что Table is full. При этом копируется где-то 40000 записей. Офигеть. Учитывая, что я выдал один гигабайт под это безобразие - он утверждает, что все, нету места. Смотю размер таблицы - данным объемом даже и не пахнет. Оказывается, что, создавая структуру, надо еще и "намекнуть", сколько записей вы бы хотели в нее положить. Через MAX_ROWS.
Пересоздаю структуру, ставлю 1000000 строчек (чтоб уж наверняка), запускаю копирование данных... Мистика - 5 секунд. Да, за 5 секунд создается таблица в памяти размером в 110 мегабайт со всеми нужными индексами. Тестирую рейтинг - по 1-2 секунды на страницу, независимо от того, первая она или где-то в серединке. Дело за малым - написать скрипт, разделяющий и обновляющий данные. Собственно, тут все казалось совсем тривиальным: DELETE FROM ... ; INSERT INTO ... SELECT * FROM. (TRUNCATE средствами PHP не поддержвиается) Написал, протестировал. Вроде, работает. Запустил сервисы сайта в полном объеме.
Почти ушел спать, глянул краем глаза - и снова расстроился. Поскольку фактическое первое, что было написано для сайта - это логер всех запросов с ошибкой, там творились страшные вещи: Deadlock. Т.е. транзакции, которые приходились на момент копирования, блокировались копированием и, не захотев ждать, отваливались. При этом само копирование тоже "падало", независомо от того, в какой момент приходилась транзакция. Значит, надо все копирование "запихнуть" в одну транзакцию, предварительно мануально проставив локи. Дополняю скрипт в начале: SET autocommit = 0; START TRANSACTION; LOCK TABLES <source> READ, <destination> WRITE; и в конце ставлю COMMIT; SET autocommit = 1;. Но не тут-то было. Если DELETE находится внутри LOCK - скрипт "падает" из-за того, что ему резко не хватает памяти. Я даже представить не могу, как связан LOCK и DELETE, но, если поставить DELETE до LOCK - все работает без ошибок, не загружая сервер и память.
И пока, хвала Всевышнему, уже 13 часов работает без сбоев. Что интересно, загрузка сервера от сортировки и содержания двух таблиц в MEMORY меньше, чем без них средствами MyISAM/InnoDB. Необъяснимо, но факт.
Вот такой вот забавный секс до 4ех утра. :))
|
|
| |
|
|
| 02.08.09 00:55 |
fido_nety | Вернулся с отпуска |
ru |
Здравствуйте мои ненаглядные.. спешу сообщить что я, таки, вернулся в целости и сохранности с отпуска.
Итак, итоги..
Ехал я туда с благородной целью загореть, отдохнуть, обьездить куеву тучу мест. В итоге почти все оставил на дне морском ... но как всегда, нигде я толком не побывал, за-то закончил Adwanced Open Diver. в общей сложности накатал 3000 км.
Свершилась мечта идиота - нырнул на 40 метров, красиво там.. на глубине, но пипец как холодно - 10 С.
Загорел чуть-чуть :) да-да.. на удивление... теперь не сильно похож на офисный белый планктон.
Купил себе штаны - цвета хаки, давно мечтал и белую стрейчевую футболку.
Возомнил себя фотографом. да .. и такое бывает.
Постараюсь завтра себя пересилить и выложить самые интересные фотки с комментариями, а пока спать спать и еще раз спать
P.S. главная новость - у меня спиз... спионерили почти пол урожая в контакте... Ахуеть товарищи...и рыбки сдохли.. ну хрен с ними.
|
| Comments: 6 | |
| |
|
|
| 01.08.09 23:40 |
Die Katze | Если тебя нет, то и меня нет... |
ru |
Вот и сегодня Ёжик сказал Медвежонку:
— Как всё–таки хорошо, что мы друг у друга есть!
Медвежонок кивнул.
— Ты только представь себе: меня нет, ты сидишь один и поговорить не с кем.
— А ты где?
— А меня нет.
— Так не бывает, — сказал Медвежонок.
— Я тоже так думаю, — сказал Ёжик. — Но вдруг вот — меня совсем нет. Ты один. Ну что ты будешь делать?..
— Переверну все вверх дном, и ты отыщешься!
— Нет меня, нигде нет!!!
— Тогда, тогда… Тогда я выбегу в поле, — сказал Медвежонок. — И закричу: «Ё-ё-ё-жи-и-и–к!», и ты услышишь и закричишь: «Медвежоно-о-о–ок!..». Вот.
— Нет, — сказал Ёжик. — Меня ни капельки нет. Понимаешь?
— Что ты ко мне пристал? — рассердился Медвежонок. — Если тебя нет, то и меня нет.Понял?…
|
| Comments: 4 | |
| |
|
|
| updated 18.06.12 18:55 01.08.09 11:24 |
Rand | Полезные вкусняшки |
ru |
1) Достаточно часто при зависании верхнего (или как еще говорят боевого) фрейма в магазине при покупке или продаже вещей с зависанием борются, просто обновляя страницу. Не смотря на то, что при обновлении выскакивает табличка-предупреждение о том, что страница была создана с передачей в сеть данных (если перед этим покупали или продавали, что либо) все равно жмут подтверждение. Как результат или покупают не то, или продают то, что не собирались. Рекомендация: При выскакивании таких табличек обновлять верхний фрейм обновлять не кнопкой "обновить страницу" (или F5) а через заход в список друзей, и тому подобное.
P.S. Я в курсе, что в идеале зависаний не должно быть. Но избавится от них полностью невозможно никак. И зависит это не от меня.
P.P.S. Список будет пополнятся.
|
| Comments: 4 | |
| |
|
|
| 01.08.09 03:49 |
Mitja | О социуме в БК |
ru |
Так получилось, что неделю назад у меня сдох комп.
Работал, работал и сдох...
Ладно бы блок питания сгорел - заменить не сложно. А сгоревшую мать менять вместе с процессором - проще новый собрать. Да и старенький он у меня был. Все равно менять пора было.
Свободной штуки баксов на руках не было - пришлось неделю сидеть дома без сети. А на работе не до БК сейчас.
Так вот о социуме...
Захожу сегодня вечером на ЧП. Нормальные люди на него заезжают, а я захожу.. От офиса метров пятьсот.
- Тебя чего в БК не видно последнюю неделю?
- Комп сгорел..
- Чинить будешь?
- Ну нафиг.. новый соберу.
- Ну пока соберешь.. Возьми пока мой на время. Я все равно дома только ноутом пользуюсь.
После ЧП поехали.. Забрал системный блок. Вполне приличный четвертый пень.
Что интересно - я не уверен, что у человека есть мой мобильный, не говоря уже про адрес или паспортные данные.
Да.. про социум.
Умер БК-шный социум. Мы его года полтора назад всем Бойцовским клубом хоронили.
Не стимулировали его развитие админы - вот он и дал дуба.
Такие дела...
|
| Comments: 4 | |
| |
|
|
| updated 11.08.09 23:12 01.08.09 02:04 |
Инви | В горе, и в радости... пока блок не разлучит вас.. |
ru |
А сегодня мне сделали предложение в БК... приятно)) Было ужасно приятно и неожиданно... И я пребывала в шоке пару десятков минут... Потому что о таком даже и не думала и не гадала.
А через несколько часов последовало второе предложение руки, сердца и, кажется, даже ноги... Не знаю... в шутку или нет, но ввергло во второй шок. Ну разве так можно?
В-третьих, только поделишься с кем-то секретом этой радости... Так уже и третья просьба руки... Блин. Странно все так.
Немного о себе: Была замужем за Neonytch'ем 3 года (если не ошибаюсь). Для меня даже в какой-то игре все было серьезно. Правда он потом пропал из поля зрения на целых 1.5 года... Но я верила и ждала.) После того, как перса потёрли я решила развестись. Целый год ходила в разводе...и тут на тебе...
В общем моя ф шоке...
Придётся отказать всем троим... Обидно ...как-то..
Дорогие они мне... Люди.
Mood: задумчивое 
|
|
| |
|
Total posts: 15324 Pages: 1533
1.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 100.. 110.. 120.. 130.. 140.. 150.. 160.. 170.. 180.. 190.. 200.. 210.. 220.. 230.. 240.. 250.. 260.. 270.. 279 280 281 282 283 284 285 286 287 288 289 290.. 300.. 310.. 320.. 330.. 340.. 350.. 360.. 370.. 380.. 390.. 400.. 410.. 420.. 430.. 440.. 450.. 460.. 470.. 480.. 490.. 500.. 510.. 520.. 530.. 540.. 550.. 560.. 570.. 580.. 590.. 600.. 610.. 620.. 630.. 640.. 650.. 660.. 670.. 680.. 690.. 700.. 710.. 720.. 730.. 740.. 750.. 760.. 770.. 780.. 790.. 800.. 810.. 820.. 830.. 840.. 850.. 860.. 870.. 880.. 890.. 900.. 910.. 920.. 930.. 940.. 950.. 960.. 970.. 980.. 990.. 1000.. 1010.. 1020.. 1030.. 1040.. 1050.. 1060.. 1070.. 1080.. 1090.. 1100.. 1110.. 1120.. 1130.. 1140.. 1150.. 1160.. 1170.. 1180.. 1190.. 1200.. 1210.. 1220.. 1230.. 1240.. 1250.. 1260.. 1270.. 1280.. 1290.. 1300.. 1310.. 1320.. 1330.. 1340.. 1350.. 1360.. 1370.. 1380.. 1390.. 1400.. 1410.. 1420.. 1430.. 1440.. 1450.. 1460.. 1470.. 1480.. 1490.. 1500.. 1510.. 1520.. 1530..
|
|
| Mo |
Tu |
We |
Th |
Fr |
Sa |
Su |
| | | 1 | 2 | 3 | 4 | | 5 | 6 | 7 | 8 | 9 | 10 | | | 12 | 13 | 14 | 15 | 16 | 17 | 18 | | 19 | 20 | 21 | 22 | 23 | | 25 | | 26 | 27 | 28 | 29 | 30 | 31 | |
|
