Ayola.net
Новости: В связи с обилием спама, постинг на форуме временно закрыт.

Для связи с поддержкой используйте тикеты в панели управления.
 
*
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь. Июль 16, 2018, 04:09:48


Войти


Страниц: 1 [2] 3
  Печать  
Автор Тема: Перегрузки MySQL и заблокированные аккаунты.  (Прочитано 59516 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Astraller™
Маэстро
*****

Карма: 151
Сообщений: 1389

Вселенское зло


Просмотр профиля WWW
« Ответ #25 : Июнь 07, 2008, 00:40:24 »

Вместо SELECT * FROM table могу написать везде SELECT 'имя поля', 'имя поля2' FROM table
Поможет?
И почему не использую индексы? Я добавил индексы почти в каждую таблицу по некоторым полям.
Неа Улыбающийся Поможет:
SELECT `field` FROM `table` WHERE `id` > 500 ORDER BY `id` ASC LIMIT 0,1 Улыбающийся
Но такие поправки просто так не вносятся, тут надо понимать всю логику скрипта и знать его как свои 5 пальцев.
Цитировать
И почему не использую индексы? Я добавил индексы почти в каждую таблицу по некоторым полям.
То что вы их добавили не значит что вы их используете Улыбающийся
« Последнее редактирование: Июнь 07, 2008, 00:43:19 от Astraller™ » Записан

Гамлета здесь больше нет. Осталась только тень.
support@ayola.net
Вне категорий
Маэстро
*****

Карма: 267
Сообщений: 4901



Просмотр профиля WWW
« Ответ #26 : Июнь 07, 2008, 00:50:42 »

2. База крайне плохо продумана (поделите число RF на число SC - мелкие таблицы используете? Или множественные запросы одну и ту же таблицу?)
3. Вы не используете индексы. Это совсем плохо.
Вместо SELECT * FROM table могу написать везде SELECT 'имя поля', 'имя поля2' FROM table
Поможет?
И почему не использую индексы? Я добавил индексы почти в каждую таблицу по некоторым полям.
Вам уже писали - ошибка бывает не только в одном запросе, но и в самом алгоритме.
И это как раз ваш случай.

Как пример - у вас в базе всего 18 таблиц. Но в среднем у вас получается за одну 30.9 селектов. А ещё апдейты есть и инсерты.

Вам не кажется странным, что из 18 таблиц вы запрашиваете данные 31 раз?
Это и есть ошибка алгоритма.


Потом, по индексам. Я бы не писал про индексы, если бы предварительно не проверил ваши таблицы на предмет наличия индексов.
Записан

Бесплатный хостинг с PHP и MySQL

Вопросы и ответы - http://faq.ayola.net
Правка .htaccess - http://htaccess.ayola.net
Техподдержка - http://www.ayola.net/panel/tickets.php
По вопросам хостинга личные сообщения не пишите. Для этого есть тикеты.
Sergiy
Старший Новичёк
**

Карма: 5
Сообщений: 95


Отец Сергий


Просмотр профиля WWW
« Ответ #27 : Июнь 07, 2008, 02:24:13 »

Отключил логин в игру, больше перегрузок не будет.

Кстати, кто оптимизирует мне что-ть?
Подарю русифицированный 100% рабочий скрипт игры + ещё некоторое вознаграждение  Строит глазки
Записан

support@ayola.net
Вне категорий
Маэстро
*****

Карма: 267
Сообщений: 4901



Просмотр профиля WWW
« Ответ #28 : Июнь 07, 2008, 02:31:27 »

Вы не осознаёте глубину проблемы Улыбающийся

Ваш скрипт при минимальном количестве пользователей кренит _выделенный_ 8 ядерный сервер с 8 гигабайтами оперативки, и рейдом дисков.

Вы только на секундочку представьте, что будет когда у вас будет хотябы 1000 пользователей...
Записан

Бесплатный хостинг с PHP и MySQL

Вопросы и ответы - http://faq.ayola.net
Правка .htaccess - http://htaccess.ayola.net
Техподдержка - http://www.ayola.net/panel/tickets.php
По вопросам хостинга личные сообщения не пишите. Для этого есть тикеты.
DLE user
Маэстро
*****

Карма: 78
Сообщений: 1692



Просмотр профиля WWW
« Ответ #29 : Июнь 07, 2008, 02:37:45 »

Вы только на секундочку представьте, что будет когда у вас будет хотябы 1000 пользователей...
А что будет?)
Записан
support@ayola.net
Вне категорий
Маэстро
*****

Карма: 267
Сообщений: 4901



Просмотр профиля WWW
« Ответ #30 : Июнь 07, 2008, 02:39:54 »

А ничего не будет. Вечный даун сервера. По причине завала дисковых операций.
Этот скрипт не выдержит нагрузки.
Записан

Бесплатный хостинг с PHP и MySQL

Вопросы и ответы - http://faq.ayola.net
Правка .htaccess - http://htaccess.ayola.net
Техподдержка - http://www.ayola.net/panel/tickets.php
По вопросам хостинга личные сообщения не пишите. Для этого есть тикеты.
DLE user
Маэстро
*****

Карма: 78
Сообщений: 1692



Просмотр профиля WWW
« Ответ #31 : Июнь 07, 2008, 02:41:28 »

А ничего не будет. Вечный даун сервера. По причине завала дисковых операций.
Этот скрипт не выдержит нагрузки.
Ужс Улыбающийся Понятное дело почему заблокировали... Улыбающийся
PS спс альену за помощь в выборе мамы Улыбающийся Да и проца тоже, хотя я 7200 и хотел  Подмигивающий
« Последнее редактирование: Июнь 07, 2008, 02:47:21 от DLE user » Записан
Astraller™
Маэстро
*****

Карма: 151
Сообщений: 1389

Вселенское зло


Просмотр профиля WWW
« Ответ #32 : Июнь 07, 2008, 02:48:05 »

+ ещё некоторое вознаграждение  Строит глазки
А вот с этого места поподробнистее....
Записан

Гамлета здесь больше нет. Осталась только тень.
DLE user
Маэстро
*****

Карма: 78
Сообщений: 1692



Просмотр профиля WWW
« Ответ #33 : Июнь 07, 2008, 02:49:03 »

+ ещё некоторое вознаграждение  Строит глазки
А вот с этого места поподробнистее....
Ксати, корас ты хотел игрушки поизучать...Судьба Улыбающийся
Записан
Sergiy
Старший Новичёк
**

Карма: 5
Сообщений: 95


Отец Сергий


Просмотр профиля WWW
« Ответ #34 : Июнь 07, 2008, 02:55:01 »

Не надо их сжигать! Этот скрипт исправляют во всём мире. И в Германии, и во Франции и в Англии.
Всего то 18 небольших таблиц БД и 2 Mb скрипта.
И проблема известна. В основном БД вешают события при полёте флотов и работе таблицы fleets:

Fleet events can do load raising too. That happens when fleet touch planet (fleetmess = 1). Imagine situation when a lot ppl does refreshing of overview, in few sec before attack (I mean both sides). Current fleet handler does table locking, but that was not good, because a lot locked threads will wait and consume a lot of memory and cpu too.
So best way was to NOT USE locking method, and to change it by adding one more field in fleets table. For example 'in_progress'.

What that mean?

When fleet arrive to planet (fleetmess=1) then player who FIRST does overview and that starting to manage fleet event, he will also mark about that fleet that there is started instance for them with 'in_progress = 1' flag. Next reloading for same event will be ignored. That was hard way to optimize fleet handling code but it was better then table locking.
http://ks32793.kimsufi.com/forum/viewtopic.php?f=23&p=8827
Это написано и на француском форуме и на итальянском...
Вот бы кто из России реализовал, прославился бы на весь мир. Улыбающийся
И я бы со всех игроков полгода отправлял бы налог герою.
Записан

DLE user
Маэстро
*****

Карма: 78
Сообщений: 1692



Просмотр профиля WWW
« Ответ #35 : Июнь 07, 2008, 02:57:05 »

Я подозреваю кто будет героем.. xD
Записан
trancemusic
Новичёк
*

Карма: -1
Сообщений: 15



Просмотр профиля
« Ответ #36 : Июнь 07, 2008, 02:57:42 »

дак, а что про мой случай? Мне нужно что-то исправлять или всё ок?
Записан
Astraller™
Маэстро
*****

Карма: 151
Сообщений: 1389

Вселенское зло


Просмотр профиля WWW
« Ответ #37 : Июнь 07, 2008, 03:00:27 »

Fleet events can do load raising too. That happens when fleet touch planet (fleetmess = 1). Imagine situation when a lot ppl does refreshing of overview, in few sec before attack (I mean both sides). Current fleet handler does table locking, but that was not good, because a lot locked threads will wait and consume a lot of memory and cpu too.
So best way was to NOT USE locking method, and to change it by adding one more field in fleets table. For example 'in_progress'.

What that mean?

When fleet arrive to planet (fleetmess=1) then player who FIRST does overview and that starting to manage fleet event, he will also mark about that fleet that there is started instance for them with 'in_progress = 1' flag. Next reloading for same event will be ignored. That was hard way to optimize fleet handling code but it was better then table locking.
http://ks32793.kimsufi.com/forum/viewtopic.php?f=23&p=8827
Переведите, а...
Записан

Гамлета здесь больше нет. Осталась только тень.
Tenzor
Новичёк
*

Карма: 0
Сообщений: 4


Просмотр профиля
« Ответ #38 : Июнь 07, 2008, 03:19:38 »

Доброго времени суток. Являюсь одним из подопытных Sergiy. Возмущён криворукостью (либо, исходя из языков коментариев скрипта, - недопониманием) кодеров сиеи игры. Вобщем, решить вопрос кода игры - значит полностью её переписать... Неслабое задание - не так ли?
Посему - спокойного сна не предвидеться. Однако лично у меня возникает вопрос - есть ли какое-то оптимальное соотношение для он-лайн игр? Где тот рай, к которомы мы должны стремиться?
Благодарствую!
Записан
Sergiy
Старший Новичёк
**

Карма: 5
Сообщений: 95


Отец Сергий


Просмотр профиля WWW
« Ответ #39 : Июнь 07, 2008, 03:24:46 »

Переведите, а...
События при полёте флотов могут загрузить сервер. Это случается, когда флот игрока прикасается  к планете (fleetmess = 1). Т.е. при атаке планеты, посадке, и т.д. Вообразите ситуацию, когда много игроков делают обновление обзора событий игры, в нескольких секундах перед нападением (Я подразумеваю обе стороны, атакующих и ждущих атаку).
Игровой обработчик событий полётов делает LOCK table, но это не хорошо, потому что много запертых заданий будут ждать и потреблять много памяти и cpu так же. Хороший способ должен НЕ ИСПОЛЬЗОВАТЬ locking  метод, а вместо этого можно добавить в таблицу флотов ещё одно поле. Например, «in_progress» (''не выполнено'').
Что это значит?
Когда флот прибывает к планете (fleetmess=1) тот игрок, кто ПЕРВЫй делает обзор событий, запускает просчёт событий, случившихся со флотам, событий с флагом ''in_progress = 1''. Потом, после обновления страницы, такие  события будет уже игнорироваться. Это путь неглубоко оптимизировать  обработку кода, но это лучше, чем LOCK table.
Записан

Astraller™
Маэстро
*****

Карма: 151
Сообщений: 1389

Вселенское зло


Просмотр профиля WWW
« Ответ #40 : Июнь 07, 2008, 03:26:03 »

Доброго времени суток. Являюсь одним из подопытных Sergiy. Возмущён криворукостью (либо, исходя из языков коментариев скрипта, - недопониманием) кодеров сиеи игры. Вобщем, решить вопрос кода игры - значит полностью её переписать...
Нифига не понял Улыбающийся
Цитировать
Неслабое задание - не так ли?
Согласен.
Цитировать
Посему - спокойного сна не предвидеться. Однако лично у меня возникает вопрос - есть ли какое-то оптимальное соотношение для он-лайн игр? Где тот рай, к которомы мы должны стремиться?
Благодарствую!
Не более чем для остальных сайтов Подмигивающий
Записан

Гамлета здесь больше нет. Осталась только тень.
Astraller™
Маэстро
*****

Карма: 151
Сообщений: 1389

Вселенское зло


Просмотр профиля WWW
« Ответ #41 : Июнь 07, 2008, 03:31:13 »

События при полёте флотов могут загрузить сервер. Это случается, когда флот игрока прикасается  к планете (fleetmess = 1). Т.е. при атаке планеты, посадке, и т.д. Вообразите ситуацию, когда много игроков делают обновление обзора событий игры, в нескольких секундах перед нападением (Я подразумеваю обе стороны, атакующих и ждущих атаку).
Игровой обработчик событий полётов делает LOCK table, но это не хорошо, потому что много запертых заданий будут ждать и потреблять много памяти и cpu так же. Хороший способ должен НЕ ИСПОЛЬЗОВАТЬ locking  метод, а вместо этого можно добавить в таблицу флотов ещё одно поле. Например, «in_progress» (''не выполнено'').
Что это значит?
Когда флот прибывает к планете (fleetmess=1) тот игрок, кто ПЕРВЫй делает обзор событий, запускает просчёт событий, случившихся со флотам, событий с флагом ''in_progress = 1''. Потом, после обновления страницы, такие  события будет уже игнорироваться. Это путь неглубоко оптимизировать  обработку кода, но это лучше, чем LOCK table.
Все бы ничего но при действительно большой нагрузке это не сработает Улыбающийся Ибо пользователь может получить данные обсчета до их рассчета в случае если ''in_progress = 1'' будет ставить _до_ рассчета, и может быть случай когда два игрока начнут обсчет если ''in_progress = 1'' ставится _после_ рассчета Улыбающийся

Решение тут, имхо одно - переложить рассчет на БД Улыбающийся Т.е. что-бы весь рассчет боя проводился 1 запросом. Улыбающийся Это сразу же повысит и скорость работы скрипта Улыбающийся Ибо БД являясь скомпиленным приложением обрабатывается в разы быстрее некомпилящихся скриптов.

Сие моя ИМХА Улыбающийся
Записан

Гамлета здесь больше нет. Осталась только тень.
support@ayola.net
Вне категорий
Маэстро
*****

Карма: 267
Сообщений: 4901



Просмотр профиля WWW
« Ответ #42 : Июнь 07, 2008, 03:40:32 »

А давайте вы будете экспериментировать на локалхосте?
Вот прямо сейчас "при отключенной игре" откудо-то нарисовалась огромная нагрузка на базе игры...
Записан

Бесплатный хостинг с PHP и MySQL

Вопросы и ответы - http://faq.ayola.net
Правка .htaccess - http://htaccess.ayola.net
Техподдержка - http://www.ayola.net/panel/tickets.php
По вопросам хостинга личные сообщения не пишите. Для этого есть тикеты.
Tenzor
Новичёк
*

Карма: 0
Сообщений: 4


Просмотр профиля
« Ответ #43 : Июнь 07, 2008, 03:46:53 »

Переведите, а...
Да запросто!
События прибывания флотов могут подвисать. Это происходит в те моменты, когда флот прибывает на планету (fleetmess = 1). Представьте себе ситуацию, когда множесто игроков обновляет обзор за несколько секунд до атаки (я имею в виду обе стороны). Текущий обработчик событий блокирует таблицу, что не есть хорошо: множество блокировок таблицы будут создавать "ожидания" и занимать много памяти и процессорного времени. Таким образом лучший выход состоит в том, чтобы НЕ ИСПОЛЬЗОВАТЬ метод блокировки, а изменять сам метод, добавляя еще одну переменную в таблицу флотов. Например 'in_progress'. Что это означает? Когда флот достигает планеты (fleetmess = 1) и первый игрок делает смену обзора - он автоматически стартует процесс управления флотов, которые отмечает произошедшие события флагом 'in_progress = 1'. При следующих перезагрузках эти события уже будут проигнорированы. Всё это значительно оптимизирует код обработчика событий, и куда лучше срабатывает, нежели блокировка таблицы!
Я подозреваю кто будет героем.. xD
Я!  Веселый
Это написано и на француском форуме и на итальянском...
Вот бы кто из России реализовал, прославился бы на весь мир. Улыбающийся
И я бы со всех игроков полгода отправлял бы налог герою.
Эх... Боюсь я Украину прославлять буду... Но я думаю - это не плохо!
Записан
blizzardportal
Просветлённый
****

Карма: 15
Сообщений: 481


Are You Dead Yet ?


Просмотр профиля
« Ответ #44 : Июнь 07, 2008, 03:53:30 »

А давайте вы будете экспериментировать на локалхосте?
Вот прямо сейчас "при отключенной игре" откудо-то нарисовалась огромная нагрузка на базе игры...

Если скрипт положил 8-ми ядерного монстра, какой же домашний компьютер выдержит такие терзания ? =)

И еще. У меня на сайте выполняется 28 - 32 SQL запроса время генерации страниц не превышает 0,3сек - это средненько? И можно тоже выписку из нагрузок на БД =)
Записан

Премиум аккаунты на rapidshare.com
1 мес 7 WMZ
Гарантия на весь срок обслуживания. ICQ=893-542
Tenzor
Новичёк
*

Карма: 0
Сообщений: 4


Просмотр профиля
« Ответ #45 : Июнь 07, 2008, 04:04:02 »

Чур, мой перевод лучший!
Есть также следующая ситуация - себе игру пока не поставил, но некоторый код уже успел написать. Однако есть проблемы с пониманием самого кода - он выдаёт ошибку. Думаю - её исправление возможно в ближайшее время. Однако снимет ли это нагрузку на сервер? Не думаю - скорее лишь более равномерно распределит во времени.
Записан
Sergiy
Старший Новичёк
**

Карма: 5
Сообщений: 95


Отец Сергий


Просмотр профиля WWW
« Ответ #46 : Июнь 07, 2008, 04:11:51 »

Localhost, боюсь, ничего не даст. На нём же не будет 40 человек в онлайне и назрузки у меня, например, на Денвере, не ощущается...
Записан

Tenzor
Новичёк
*

Карма: 0
Сообщений: 4


Просмотр профиля
« Ответ #47 : Июнь 07, 2008, 04:25:47 »

На нём же не будет 40 человек в онлайне
Ну - не совсем так. Как я уже писал - главное иметь текущую таблицу реальной игры. И любое действие игрока будет провоцировать "решение" текущей ситуации... А для того, чтобы спроэцировать полученный результат на "реальное положение дел" нужно просто помножить ситуацию на 50-60 - именно такая цифра, примерно, последнее время фигурировала в качестве игроков он-лайн.
Господа хостеры - "я п'рав или не п'рав?" (С)
Записан
support@ayola.net
Вне категорий
Маэстро
*****

Карма: 267
Сообщений: 4901



Просмотр профиля WWW
« Ответ #48 : Июнь 07, 2008, 04:52:30 »

Вы абсолютно правы.
Только не надо умножать. Нагрузка, увы, не всегда растёт линейно, особенно для MySQL.

Самое лучше - использовать что-либо наподобие ab. Эта тулза идёт в комплекте с апачем, и представляет из себя простейшего бота который умеет имитировать нагрузку.

Вы делаете скрипт А1, который рандомом дёргает один из реальных скриптов игры (Б1, Б2, Б3, Б4 итд), и обязательно передаёт им псевдореальные параметры, как-будто играют реальные люди.
Когда эти скрипты будут готовы - вы делаете простую вещь. Натравливаете в несколько потоков ab на скрипт A1, и смотрите на нагрузку.

А можно вместо ab - написать свою дёргалку, она бы ещё и затыки фиксировала по вашим меткам.

Таким образом у вас всегда должен быть дев-сервер, и прод-сервер.
Любое изменение софта делается на дев-сервере, и на нём ТЩАТЕЛЬНО тестируется и на совместимость, и на производительность. И только когда ВСЁ выверено - вы выкладываете содержимое дев-сервера на прод-сервер. И радуетесь жизни Улыбающийся


Это - единственный путь. Никто не занимается отладкой на прод-серверах.
Записан

Бесплатный хостинг с PHP и MySQL

Вопросы и ответы - http://faq.ayola.net
Правка .htaccess - http://htaccess.ayola.net
Техподдержка - http://www.ayola.net/panel/tickets.php
По вопросам хостинга личные сообщения не пишите. Для этого есть тикеты.
remell
Новичёк
*

Карма: 0
Сообщений: 19


Просмотр профиля
« Ответ #49 : Июнь 10, 2008, 02:29:16 »

Стесняюсь спросить, мой сайт тоже заблочен? Что делать, как быть? remell.md8.ru
Записан
Страниц: 1 [2] 3
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.13 | SMF © 2006, Simple Machines LLC

2003-2008 © ООО "Инфотур" - Бесплатный хостинг Ayola.net
Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Страница сгенерирована за 0.139 секунд. Запросов: 17.