login:        password:      
Combats Scrolls
Rambler's Top100
Гость БК
Свою историю жизни мы пишем сами! | SSPOOKSS Open user info Open user photogallery
Friend page
updated 07.08.09 00:54
06.08.09 00:24   |  Посеша Open user info Open user photogallery |   
 ru
 Вы получили подарок от Ангела..
6 лет в Клубе... это оочень много... наверно слишком )))
Comments: 9 | Post comment
updated 07.08.09 00:48
05.08.09 23:08   |  Посеша Open user info Open user photogallery |   Про девочку...
 ru
Comments: 17 | Post comment
updated 03.08.09 22:39
03.08.09 22:38   |  Лизка Open user info Open user photogallery |   Все каллории - в сиськи! (с)
 ru
 Помните такое выражение?:)
Я заметила, что если дать себе такую установку - так и будет! На ровном месте - без ощутимого увеличения веса (+/-0,5 кг) - "сиськи" увеличились на полразмера!))) Мысль - материальна, воистину:)

Mood: хитрое 
Music: Real O - Я Бы...
tags: реал
Comments: 64 | Post comment
03.08.09 21:21   |  Лизка Open user info Open user photogallery |   Пора в школу:)  ru
 Персонажу "Лизка" 7 лет:) Случайно зашла и вспомнила. Такие дела:)

Mood: сонное 
Music: Мика Ньютон - Выше Чем Любовь
tags: БК
Comments: 20 | Post comment
updated 07.08.09 00:49
02.08.09 23:16   |  Посеша Open user info Open user photogallery |   
 ru
Comments: 4 | Post comment
updated 02.08.09 19:00
02.08.09 18:10   |  kirillica Open user info Open user photogallery |   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ех утра. :))
tags: MySQL fun
Post comment
updated 07.08.09 00:54
31.07.09 21:32   |  Посеша Open user info Open user photogallery |   
 ru
 Узнала сегодня о себе много нового )))))
Пройдя несколько тестов...
Итак.. кто я на самом деле )))



* Душа моя окрашена в...серый цвет CUT: ...

* В прошлой жизни я родились в… Непале CUT: ...

* Моя любвь - это Платоническая любовь CUT: ..

* В лесу бы я встретила огромного серого волка CUT: ...

* Из сладкого я… Мармеладка CUT: ..

* Из всех фея я бы подружилась с феей... Иридессой CUT: ..

* Из зверей я, конечно... Змея CUT: ..

* Во мне бушуют все времена года! :) CUT: ...

* Из фруктов я... банан. CUT: ..

* Из всей куханной утвари я - Мясорубка! CUT: ..

* Мой музыкальный инструмент - Губная гормошка.

* Мой персональный смертный грех - Алчность/жадность CUT: ..

* Из карточных мастей я - черви CUT: ..

* В средневековом обществе я бы занимала одну из высоких ступеней - и носила бы титул графини.

* Из всех героиню советского экрана я похожа на - француженка Полина Гебль, декабристка Анненкова из фильма " Звезда пленительного счастья" CUT: ..
Comments: 9 | Post comment
updated 07.08.09 00:49
31.07.09 19:47   |  Посеша Open user info Open user photogallery |   Let's Do The Things We Normally Do.. ))
 ru
Comments: 7 | Post comment
29.07.09 18:38   |  Ugl Open user info Open user photogallery |   Ищу автора текста.  ru
 Действующие лица:
Он - мужчина ср. лет, ср. телосложения, падонок.
Она - Девочка - блондинка, 23 года, хорошая фигура и внешность, из приличной семьи, случившиеся в жизни мужчины - сплошь "папики",носящие ее на руках и сдувающие пыль с ее ног.
17.30 (Центр).
- Он: "Алло, привет, какие планы на вечер?"
- Она: "Пока никаких, а что?"
- Он: "Приглашают на шашлык, недалеко тут, поедешь?"
- Она: "Супер! Поеду, а во сколько?"
- Он: "21.00 надо быть на месте"
- Она: "ОК, я после восьми буду на набережной, созвонимся"
20.25 (Центр)
- Он: "Ты на набережной?"
- Она: "Да! Немножко занята!"
- Он: "В смысле?!"
- Она: "Подружку встретила, зашли в кафе поболтать, перезвони минут через десять!
20.41 (Центр)
- Он: "Алло, ну что?"
- Она: "Все, сейчас едем, мы тут с Викой кофе пьем, заезжай за нами!"
- Он: "В смысле "за нами"?"
- Она: "Ну, подбросим ее до дома, а то она в Чертаново живет... Ой, мы
тут еще десерт заказали: Ты минут через пятнадцать подъезжай лучше,ОК?!"
- Он: "ОК" (едет домой)
21.22 (Он ставит машину на стоянку, пересаживается в машину друга,едет за город)
- Она: "Алло, ты нас ждешь?"
- Он: "Конечно"
- Она: "Мы еще немного посидим, ликер заказали: Мы же с Викой неделю не виделись!"
- Он: "Да без проблем"
22.05 (Подмосковье, Он уже порядком выпил, собирается делать шашлык)
- Она: "Привет! А тут классно! Мы еще ликерчика заказали... ик... Только дорогой он тут..."
- Он: "Не беспокойся, я за вас заплачу, не стесняйтесь"
- Она: "Ну, мы тогда еще и десерт повторим?"
- Он: "Ну, конечно, я пока в машине подожду..."
22.45 (Подмосковье, Он кушает шашлык и флиртует с девушками)
- Она: "Алло! Мы тут Наташку повстречали, она со своим парнем, мы их в Митино отвезем?"
- Он: "Конечно отвезем... Угости, их, кстати тоже ликером..." (Сдавленно ржет)
23.25 (Подмосковье, все уже в курсе, Его телефон включен на "громкую связь")
- Она: "Ну, мы уже готовы ехать... Ждем тебя"
- Он: "Да, сейчас подъеду... На сколько там счет?"
- Она: "Пять восемьсот"
- Он: "Без проблем, ждите" (Дает отбой, так как народ ржет вповалку)
23.50 (Подмосковье, люди пьют и танцуют)
- Она: "Алло! Ну ты где?!"
- Он: "Да, друга тут встретил, надо поговорить.. Перезвони минут через десять" (Успокаивает бьющуюся в истерике компанию).
00.01 (Подмосковье, все внимательно смотрят на Его телефон)
- Она: "Ну и где ты, тут уже все официанты собрались!!"
- Он: "Ой, извини, я уже сегодня не подъеду, нам с приятелем нужно
срочно выгулять его собачку... А она аж в Измайлово... Пока! Спокойной ночи,
чмоки!"
(Телефон отключается, Он тщетно пытается ловить падающих от смеха друзей)
Занавес.
Comments: 2 | Post comment
updated 28.07.09 13:10
28.07.09 01:42   |  Ex*Фергард Open user info Open user photogallery |   О стихиях
 ru
 Подумал о том, что если встанет выбор между различными Стихиями, то однозначно выберу воздух.

1. Люблю воздух, ветер и грозу.
2. Родился под воздушным знаком зодиака.
3. Всю жизнь в БК бегал с умелками в воздухе, дрался с Кинжалами Сумеречных Гроз, и Злодейскими (воздушные атаки)
4. Просто люблю эту стихию по сравнению с остальными. Сбалансированна она как-то 8))

А какую стихию выбрали бы вы?
Какую стихию выбрали бы вы?
Огонь ( 63 / 38.4% )
Вода ( 31 / 18.9% )
Земля ( 37 / 22.6% )
Воздух ( 33 / 20.1% )
Only authorized users
Vote status: vote are opened for users
Republication tag: [vote=1707]
Comments: 11 | Post comment

Total posts: 2305 Pages: 231
«« « 1.. 10.. 20.. 29 30 31 32 33 34 35 36 37 38 39 40.. 50.. 60.. 70.. 80.. 90.. 100.. 110.. 120.. 130.. 140.. 150.. 160.. 170.. 180.. 190.. 200.. 210.. 220.. 230.. » »»
 
 


« 2025 may »
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

 
 © 2007–2025 «combats.com»
  18+  
feedback