|
| 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 | |
| |
|
|
| 24.06.09 23:47 | adminion :
Пересмешник | Берегись... |
ru |
При использовании магии нападения (нападение на кого-то или вмешательство в бой начатый магией нападения) с вероятностью:
55% персонаж, на которого совершалось нападение, пропустит ход в пользу персонажа, который нападал;
15% персонаж, который нападал, пропустит ход в пользу персонажа, на которого совершалось нападение;
30% будет обычный размен (никто не пропустит ход)
Mood: улыбчивое  Music: Глюкоза - Швайне
|
| Comments: 67 | |
| |
|
|
| 13.06.09 16:11 |
kirillica | Skype: первые ощущения |
ru |
Итак, с чего бы начать? Во-первых, попасть на работу в Skype не было никогда моей мечтой. Я как бы в принципе до определенного момента даже и не думал об этом. В тоже самое время знал, что рано или поздно то направление, в котором я работал до этого, закроют, так как клиентов, готовых инвестировать в серьезные решения по управлению бизнес-логикой становилось все меньше. Эдакая патовая ситуация, когда все говорят, понимают, что это круто и реально окупится через год-полтора максимум, но, в тоже время, абсолютно не хотят расставаться с деньгами сейчас. Бизнес средних и долгих перспектив, к сожалению, потихонечку умирает.
В один понедельник стало ясно, что очередные человеко-месяцы на разработку перспективных клиентов ушли впустую, и мы расстались с моим предыдущим работодателем. Тяжеловато было за полчаса собрать все мысли и вещи, которые стали общими за эти четыре с половиной года, но я был бы безвозвратно глуп, если бы где-то за полгода до этого момента не начал думать о запасном плане.
В первую же неделю без работы я получил три неплохих предложения. Одно - по продажам, два - по разработке. Но - не цепляло так, что бы "ух": и в деньгах не потерял бы, и люди приглашали знакомые, но что-то не то, не то. К тому же, параллельно с друзьями мы обсуждали их дипломы по магистратуре и душа просила чего-то "хорошо забытого старого". Так я случайно наткнулся на предложение от Skype, да и пара знакомых оттуда вдруг активизировались, рассказывая, как там хорошо.
Что я понял сразу - попасть в Skype не так уж и просто. Лично у меня было три тура собеседования, хотя уже на первом туре мне дали понять, что я подхожу. Причем, последний тур - с будущей командой, которая тоже должна сказать: "нам нравится этот парень". Неважно, на какую должность ты идешь, коллектив должен тебя принять, а уже потом, после всего этого, тебе присылают официальное предложение и ты первый раз узнаешь, какую же зарплату тебе готовы предложить. Поскольку особых разногласий у нас не было, наш выбор окончательно остановился друг на друге.
Вот так неожиданно (для себя образца месяца три-четыре назад) я и оказался в отделе бизнес-безопасности. Выше писал о "хорошо забытом старом" - так оно и есть. Анализ данных, прогнозы, паттерны, статистика, игра на опережение - это и есть теперь моя работа, а так же одна из моих "забытых вышек". Жутко интересно и жутко напоминает охоту. Причем, размеры оружия (или методы - кому как удобней) варьируются от гранатомета до дротика. Кровавые сцены - каждый день :)). Признаюсь, мне, единственному русскому по национальности в отделе, видеть зону "RU" в списках "нехороших пользователей" не особо приятно. Конечно, никто не посмотрит и даже не подумает о тебе ничего плохого, даже если это будет массовым явлением, но что-то где-то как-то "некомильфо" - факт.
Вообще, статус международной корпорации накладывает свои отпечатки. Во-первых, только в таллиннской конторе работает около 25-ти разных национальностей, а в гости приезжают вообще со всего света. Во время обеда столовая напоминает вавилонское столпотворение: количество языков и различных, скажем, типажей, на другие ассоциации не наводит. Да, кстати, кормят неплохо и "за счет заведения". Помимо столовой, в здании есть так же душевые, баня, комната отдыха с биллиардным столом и игровыми приставками и куча других интересных штучек, которые разбросаны по разным уголкам четырехэтажного офиса. Уютненько. В нашем отделе большие окна выходят прямо на лес, так что возможность "отвлечься взглядом" присутствует в том числе.
Еще одно ключевое слово для Skype - безопасность. Скажу честно, никогда я не слышал столько фактов и правил, сколько в первые дни здесь. Тренинги и семинары на эту тему - неотъемлемая часть обучения нового работника. Они включают в себя так же и демонстрацию "косяков", которые случались в мировой практике. Например, многие ли из вас знают, что один испанский телеком-оператор был оштрафован на миллион евро за то, что передал данные о своих клиентах своей "дочке", что бы та их проанализировала и сделала клиентам предложение на новом (для концерна) рынке? И такое, оказывается, сплошь и рядом. Что мне понравилось: если вам кто-то позвонит и начнет спрашивать всякие вопросы (типа исследования) или же делать всякие маркетинговые предложения, то на ваш вопрос "откуда мои контактные данные и вообще, почему вы звоните именно мне?" вам обязаны ответить в максимально подробной и точной форме. Вы имеете полное право знать, откуда берутся ваши данные и на основе каких исследований было решено позвонить именно вам. Более того, вы даже можете потребовать перечень всех ваших характеристик, которые использованы в исследовании. Т.е. т.н. "директорский маркетинг", как показывает практика, штука весьма тонкая и опасная. Судебных прецедентов - масса.
Ну, мы отвлеклись. Итак, общий вывод: здесь комфортно и интересно. И, как оказалось, работает много знакомых по универу. Еще раз убедился, что быть выпускником лучшего высшего учебного заведения в стране - это не пустой звук. Атмосфера - дружелюбная, рабочий язык, естественно, английский, так как даже в нашей команде есть иностранец, который, правда, уже немного понимает по-эстонски. Любимый мною корпоративный дух на должном уровне. Наверное, потому, что все работники являются акционерами Skype. Теперь и я - часть его, а у меня - часть этой "эстонской нокии".
Mood: приветливое 
|
|
| |
|
Total posts: 374 Pages: 38
1 2 3 4 5 6 7 8 9 10.. 20.. 30..
|
|
| 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 | | | | |
|
Изменен порядок выдачи награды в Башне Смерти.
