|
| updated 09.10.09 14:47 16.08.09 04:07 |
Инви   | о Любви. |
ru |
Любить - это как стоять на свежем цементе. Чем дольше стоишь - тем труднее оторваться... и никогда нельзя уйти, не оставив следов.
Mood: задумчивое 
|
| Comments: 15 | |
| |
|
|
| updated 16.08.09 03:45 16.08.09 03:43 |
Инви | мм... |
ru |
Всегда кажется, что нас любят за то, что мы хороши.
А не догадываемся, что любят нас оттого, что хороши те, кто нас любит.
© Лев Николаевич Толстой
Mood: задумчивое
|
| Comments: 5 | |
| |
|
|
| updated 14.08.09 17:55 14.08.09 17:01 |
Инви | Лучше поздно, чем никогда... ((: |
ru |
16:57 • Алтарь Крови, 99 / 99 *барабанная дробь*
16:58 Внимание! Репутация с 'Алтарь Крови' изменена на +1
Update: 14-08-09 17:53
Вы купили "Штаны Решимости [10]".
Ура! 
Mood: довольное 
|
| Comments: 10 | |
| |
|
|
| 07.08.09 20:41 |
Инви | Из моей инфы перса. |
ru |
ღ ...
Не надо вопросов. Да, я не влюблена, не хочу и не собираюсь. Любить не умею и не буду. Не лезьте в душу.
А если хотите почитать "сюси-пуси-муси" - в моей инфе вы этого не найдете, велкам в другие анкеты. Удачи.
© Инви
Music: Город 312 - Береги себя
|
| Comments: 11 | |
| |
|
|
| 03.08.09 03:09 |
Инви | Открыла "жж",вздохнула,опустила руки на клаву и... |
ru |
Устала, от всего, от всех.
А хочется в душе чудес.
Сижу, гляжу в окно, там тьма.
Вокруг меня, вокруг тебя.
Ты далеко, и я не рядом.
Не прикоснуться даже взглядом.
Тебе плевать, а мне не скрою,
За этой стенкой, этой болью
Не полюбить, не разлюбить...
И наше счастье не забыть...
И писать стихи я не умею.
И старалась даже не для вас.
На одном полете пальцев нежных,
Рассказала что в душе моей сейчас:
Боль. Отчаяннье. Немного прежних,
Никому не нужных ч.у.в.с.т.в.
Mood: задумчивое
|
| Comments: 9 | |
| |
|
|
| 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ех утра. :))
|
|
| |
|
|
| updated 11.08.09 23:12 01.08.09 02:04 |
Инви | В горе, и в радости... пока блок не разлучит вас.. |
ru |
А сегодня мне сделали предложение в БК... приятно)) Было ужасно приятно и неожиданно... И я пребывала в шоке пару десятков минут... Потому что о таком даже и не думала и не гадала.
А через несколько часов последовало второе предложение руки, сердца и, кажется, даже ноги... Не знаю... в шутку или нет, но ввергло во второй шок. Ну разве так можно?
В-третьих, только поделишься с кем-то секретом этой радости... Так уже и третья просьба руки... Блин. Странно все так.
Немного о себе: Была замужем за Neonytch'ем 3 года (если не ошибаюсь). Для меня даже в какой-то игре все было серьезно. Правда он потом пропал из поля зрения на целых 1.5 года... Но я верила и ждала.) После того, как перса потёрли я решила развестись. Целый год ходила в разводе...и тут на тебе...
В общем моя ф шоке...
Придётся отказать всем троим... Обидно ...как-то..
Дорогие они мне... Люди.
Mood: задумчивое
|
|
| |
|
|
| updated 28.07.09 18:57 28.07.09 18:55 |
quick spirit | La Roux-Colourless Colour |
ru |
|
|
|
| |
|
|
| 21.07.09 23:23 |
Инви | Хе-хе, как все сложно..) |
ru |
Запреты на смену кланов:
Нельзя вступить в клан "DCR" еще 2 мес. 1 дн.
Нельзя вступить в клан "DevilsSun" еще 1 мес. 2 дн.
Ограничения на смену склонностей:
Разрешена только склонность "Темное Братство" еще 2 мес. 1 дн.
Mood: уставшее 
|
| Comments: 12 | |
| |
|
Total posts: 471 Pages: 48
1.. 9 10 11 12 13 14 15 16 17 18 19 20.. 30.. 40..
|
|
| Mo |
Tu |
We |
Th |
Fr |
Sa |
Su |
| | 1 | 2 | 3 | 4 | 5 | | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | 13 | 14 | 15 | 16 | 17 | 18 | 19 | | 20 | 21 | 22 | 23 | 24 | 25 | 26 | | 27 | 28 | 29 | 30 | 31 | | |
|
