|
11.08.09 15:00 |
Лизка   | Блондинка - это не цвет волос... |
ru |
Несколько дней назад меня решили поучить водить машину. Мне хватило 10-ти минут, чтобы понять: механическая коробка передач - явно не мой конёк:) Да и вообще... задумалась, хочу ли я уметь водить машину. Ведь на пассажирском сидении так комфортно. И пива можно выпить всегда, не задумываясь о том, что ещё надо куда-то ехать:))
Такой беспросветной тупицей я не чувствовала себя довольно давно. М-да..:))
Mood: рабочее 
|
| Comments: 30 | |
| |
|
|
| 09.08.09 01:10 |
ACHARYA | Та ну нафик:-) |
ru |
.
|
|
| |
|
|
| 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 03.08.09 22:39 03.08.09 22:38 |
Лизка | Все каллории - в сиськи! (с) |
ru |
Помните такое выражение?:)
Я заметила, что если дать себе такую установку - так и будет! На ровном месте - без ощутимого увеличения веса (+/-0,5 кг) - "сиськи" увеличились на полразмера!))) Мысль - материальна, воистину:)
Mood: хитрое  Music: Real O - Я Бы...
|
| Comments: 64 | |
| |
|
|
| 03.08.09 21:21 |
Лизка | Пора в школу:) |
ru |
Персонажу "Лизка" 7 лет:) Случайно зашла и вспомнила. Такие дела:)
Mood: сонное  Music: Мика Ньютон - Выше Чем Любовь
|
| 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 02:18 |
melese | |
ru |
Почти звериная,нежная,
Покрытием стелится замшевым,
Тоска по Вам,неизбежный мой,
Но дальше,и дальше,и дальше Вы...
Я Вас изучаю по Млечному
Пути./Начинаю безумствовать.../
Какое заклятье на вечную..
Придумать,чтоб снова Вас чувствовать?
Теряюсь...Теряю...Теряетесь...
Покончив с любовными актами ,-
Ушли./Никогда не прощаетесь!/
Магическими артефактами,
Обрывками и тетрадями,-
Все письма мои к Вам разбросаны,
Но кем - то уже украдены,-
Вы - м н е - несомненно посланный,
Всей тьмою и всеми звёздами...
Судьба - слишком многолинейная.
Каким же Вы чудом созданы,
Вы - кто - то,кто много сильней меня?..
В полнеба луна...Сознание.
И Млечный двоится докучливо.
И Вы уже не узнаете
О том,как она меня мучает,
Почти звериная,острая,
Клыками впиваясь насильственно,-
Огромными,страшными монстрами,-
Тоска по Вам,мой единственный.
(с)
|
|
| |
|
|
| 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: 3704 Pages: 371
1.. 10.. 20.. 30.. 39 40 41 42 43 44 45 46 47 48 49 50.. 60.. 70.. 80.. 90.. 100.. 110.. 120.. 130.. 140.. 150.. 160.. 170.. 180.. 190.. 200.. 210.. 220.. 230.. 240.. 250.. 260.. 270.. 280.. 290.. 300.. 310.. 320.. 330.. 340.. 350.. 360.. 370..
|
|
| 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 | | | | | | |
|
