|
| updated 11.09.09 15:17 11.09.09 11:31 |
Ex*Фергард   | Достало! |
ru |
Если честно, сложность игры на Свежевателе Душ за Альянс меня не пугала (для тех, кто не в теме - соотношение Альянс-Орда на сервере - примерно 1 к 99).
Вчера меня добила только одна вещь - пресловутая очередь на вход. В момент моего логина она была 1241 человек, а захода в игру я ждал чуть меньше полутора часов.
Короче.
Ткач Смерти. Ночной Эльф, Рыцарь Смерти, 80. Фергард.
Информация о Персонаже
Добавляйте во френды. 8)
P.S. На Ткаче ситуация получше будет. Там примерно 40 на 60 (Альянс-Орда). И почему у нас все за Орков играть любят? 8)
|
| Comments: 4 | |
| |
|
|
| updated 26.08.09 21:31 26.08.09 21:30 |
Ex*Фергард | Почему БК лучше, чем WoW |
ru |
Там нет такого:
Ну не пиздец?
|
| Comments: 7 | |
| |
|
|
| updated 13.08.09 14:04 13.08.09 14:00 | adminion  :
Пересмешник | Чтобы защитить малышей от плохишей ) |
ru |
Отныне опыт получается только с персонажей, уровень которых не ниже 2 от Вашего уровня.
11 не получает опыт с 9 уровня.
10 не получает опыт с 8 уровня.
И т.д.
Mood: Пересмешливое Music: Mr.President - Coco Jambo
|
| Comments: 134 | |
| |
|
|
| updated 07.08.09 22:31 06.08.09 19:28 | adminion :
Повелитель Земли | Новое в кланах |
ru |
Отныне регистрация клана и вступление в клан не требуют проверки на чистоту у модераторов.
Убрана стоимость вступления и выхода из клана (теперь бесплатно).
В клан могут вступить любые персонажи, начиная с 8-го уровня.
Update: 07-08-09 22:00 Для игроков состоящих в клане добавлена возможность добровольно покинуть оный
|
| Comments: 106 | |
| |
|
|
| updated 06.08.09 19:32 06.08.09 18:33 | adminion :
Повелитель Земли | Хроники DDoS |
ru |
Для тех кто понимает...
Был syn flood на веб сервера, также на завал обоих ДНС серверов UDP flood, дальше попытка завала фаерволл-кластера за счет истощения активных коннектов (т.е. открывает соединение и подвешивает его). Но благо машинки фаерволл ноды мощные! Но первую волну syn flood мы пропустили, неожиданно мощной оказалась.
График за сутки на ближайшем к нам свиче у провайдера (он не отображает полной картины):
Обычно когда идет атака, начинающие ддосеры используют параметры статические, а здесь была динамика - изменение параметров на лету каждые 5 минут (один блок ставишь, а он через 5 минут перестает работать). Потом стали отлавливать по сегментам откуда трафик идет, много очень было из Гонконга и Вьетнама, мы роутинг до них обрубили после того как те не ответили на 4 наших запроса. Ддос после этого упал резко. Выиграли время чтобы написать пару скриптов для авто-детекта новой волны атаки. Когда пошла следующая на 700 мегабит, там был просто syn flood на уязвимое место в скриптах, потому никто не мог авторизоваться в игру (что указывает на дополнительную подготовку к проведению атаки).
Поставили rate-limiter так называемый - фиксировали количество пакетов за единицу времени, тем самым все что вылетало за рамки в блок сразу летело в мусор. И тут возникли проблемы с тем, что ИПов было сотни тысяч, таблица блока переполнилась. В результате мы пересобрали ядро на фаерволле и привинтили внешние листы для блокировок, чтобы сама таблица не была полной. Теперь до 2 миллионов уникальных IP можем держать.
Также в детекции помог провайдер TeliaSonera, они дали полные данные по типам атаки достаточно быстро. Но вот с блокировкой они тормознули, не хотели сначала ничего делать. Пришлось поднимать регионального менеджера...в результате они блокировку также и у себя выставили.
На данный момент он тихо отмирает, боты быстро не умирают сами ...
Для сравнительного анализа привожу данные графики:
график понедельный (на нем Вы можете видеть слабенькую атаку, про которую мы даже не сообщали)
P.S. Выражаем благодарность провайдерам, хостерам и всем, кто принимал участие в устранении атак, а также ддосерам (которые прекратили атаки).
|
| Comments: 48 | |
| |
|
|
| 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 31.07.09 03:02 31.07.09 03:00 | adminion :
Пересмешник | Одной строкой... |
ru |
Убрана возможность телепортации для карателей, инквизиторов, ветеранов армады и кавалеров ордена.
Mood: Пересмешливое
|
| Comments: 105 | |
| |
|
|
| updated 30.07.09 20:24 30.07.09 19:12 | adminion :
Повелитель Земли | Несколько новостей о кланах. |
ru |
Первая новость:
Клановые войны.
Теперь глава вашего клана, может объявить войну другому клану. Война может быть кровавой и обычной (определяет тип нападения).
Войны с одинаковым типом продлевают друг друга (один день кровавой войны и один день кровавой войны в результате даст два дня кровавой войны).
Войны с разным типом идут параллельно (один день кровавой войны и один день обычной войны в результате даст один день кровавой войны, потому, что у кровавой войны выше приоритет).
Продлить войну можно в любой момент. В течение этого периода времени представители враждующих сторон могут начать поединок, с помощью иконки нападения возле имени соперника из враждебного клана. Начать поединок можно в любой локации, где не запрещены бои.
Вступить в клановый бой, кроме воинов этих двух кланов никто не сможет. Вмешаться в бой можно только за свой клан.
Склонности в войне кланов не учитываются (темные кланы могут объявлять войну темным, светлые кланы - светлым).
Объявления войны, за отдельную плату, оформляется в регистратуре кланов.
Внимание! Объявление войны идет по идентификатору клана, соответствующему английскому названию клана.
Вторая новость.
Выборы.
Главу клана теперь можно выбрать путем голосования. Выдвигается кандидатура в регистратуре кланов, голосование по ней проходит со страницы клана.
И, наконец, третья новость.
Принятие в клан.
Изменен алгоритм принятия в клан. Вместо немедленного принятия, кандидату высылается приглашение, которое он вправе принять или отказаться от него.
Update: Это тестовое нововведение и все может поменяться в будущем!!!
|
| Comments: 117 | |
| |
|
Total posts: 896 Pages: 90
1 2 3 4 5 6 7 8 9 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90
|
|
| 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 | | | | | | |
|
Stalkers! 8)))
