Aisamiery: У вас запрос обрабатывает 32 304 386 строк А добавьте EXPLAIN с одним параметром, который отрабатывается быстро. У вас просто на джоинах не используються индексы, да и тип объединения чуть лучше чем ALL, но очень плохо что последний. А вообще предлагаю упрощать запросы, разбивать на подзапросы и менять структуру или вводить избыточность в таблицы.
А дамп базы можете сделать?
Интересно попробовать, но с нуля моделировать схему лень. Больше подготовительных работ, чем непосредственно процесса решения :)
dma84
Если 35 секунд на 7000 записей - дело не в индексах, ошибка именно в схеме БД.
К примеру, email_1 - email_4 - это уже непонятно, зачем денормализация в этом месте и чем вызвана (но это просто к примеру, потому что про отдельную таблицу автор уже писал, что в последнюю очередь).
Aisamiery: без EXPLAIN не понять, скорее всего там где то не юзается индекс и mysql из за этого ворочает миллионами строк, собственно по этому так и долго.
Basilisk: Ну вот поэтому и интересно на схему глянуть - готовую развернуть, чтобы не гадать.
Если там ничего секретного нет, конечно.
Хотя, данные сотрудников, плюс контакты и все такое, не уверен, что можно. Даже самому сомнительно стало :)
Но 35 секунд даже для нескольких миллионов строк много.
К сожаленью, сами понимаете, персональные данные ~7000 сотрудников, увы, не смогу :(
Решений подсказали уже несколько, спасибо всем откликнувшимся. Но тут еще есть чисто теоретический интерес, который я не совсем понимаю.
При Join с 1 емейлом - выполняется 0.1 сек
При Join с 2-мя емейлами - 33сек
При Join с 3-мя емейлами - 33сек
При Join с 4-мя емейлами - 33сек
Если мы он действительно перебил все таблицы, и затык был бы в кол-ве обрабатываемых строк - тогда в зависимости от кол-ва емейлов как-то бы изменялось время выборки, а не было практически одинаковым.
Вот и пытаюсь понять, почему Join по 1 полю - все отлично, по 2 и больше - затык, причем с одинаковой скоростью выборки.
Здравствуйте. В течении дня пытаюсь получить смс для верификации (Украина). Раз 10 уже клацал кнопку выслать код еще раз. Толку 0. У кого-то еще наблюдаются проблемы с получением СМС. Или это только мне так "повезло"?
Sujcnm: В вашем примере - будет распространяться и и на статику.
Если нужно тормознуть только вызов апача, то для этого в секцию http пропишите только это:
И тогда это правило будет применяться только для динамики в указанных виртуальных хостах.
Спасибо за ответ. У меня возник только 1 вопрос - обязательно ли для каждой локации прописывать вручную
limit_req zone=one burst=15
или достаточно прописать это в секцию - http? Понимаю, что маловероятно, но как говорится, а вдруг? :)
UnFeeLing: Что за скрипт? ОС? покажите кто-что грузит больше всего при нагрузках бд. Таблицы InnoDB или MyISAM?
top
Без шаловливого робота ВПС-ка держит нагрузку на отлично. ЛА не выше 0,1. Тут проблема именно в создании огромного кол-ва запросов от робота за единицу времени - в моем случае это 40-60 запросов/сек, на протяжении 30-40 секунд, чего достаточно, чтобы положить apache :(
kgtu5: ТС может все же не давать серверу плодить апачи чрезмерно много, тогда и база отваливаться не будет ;)
Я как бы и спрашиваю совета - верно ли мое мышление, либо нужно плясать не в сторону настройки nginx, а в сторону к-ва дочерних процессов апача. К сожалению, опыта у меня не так много в этом вопросе.
Начал тестировать данную ПП где-то с месяц назад. (как запасной вариант для основной ПП)
Что имеем: в статистике светится, что ушло в работу 3 заказа. Все, на этом статистика закачивается :) Более детально посмотреть - какой мой %, какова сумма работы и т.д. (как у других ПП) нет.
За все время - суппорт ответил только 1 раз, что в текущей версии интерфейса - не предусмотрено отображения сколько составил мой заработок :) На просьбу подсказать в ручном режиме, через их интерфейс - жду ответа уже неделю (!!!!).
Email, tickets, онлайн чат - везде тишина.
Поэтому вопрос к представителю:
Ваши слова:
- Детализированная статистика в Личном кабинете для оптимизации работы
Можно узнать, что Вы подразумеваете под детальной статистикой?
- Персональный аккаунт-менеджер поможет с выбором оптимальных бизнес моделей и ответит на все вопросы
А можно как-то откопать моего аккаунт менеджера, и хоть каким-то каналом связи пообщаться с ним?
Пока что опыт работы с Вами - крайне негативный. Отношение к партнерам - отсутствует как таковое :(
Немного проясняется. У меня не прямой договор с naunet.ru
Ресселер www.dup.ru нужно с ним решать эти вопросы.
Возможно кто-то подскажет быстрый выход на dup.ru? В тикете тишина уже 3 часа, других средств коммуникации не нахожу :(
Только что пытался вывести на карту Альфа-банка Украина, через https://telepay.wmtransfer.com/ru/operator/4191
Платеж не прошел, позвонил в суппорт, ответили, что по их инфе одна из карт заблочена, с моей все ОК, проверяйте карту отправителя.
Теперь также в поисках альтернативы для вывода WMZ на долларовую карту
У вас запрос обрабатывает 32 304 386 строк
А добавьте EXPLAIN с одним параметром, который отрабатывается быстро. У вас просто на джоинах не используються индексы, да и тип объединения чуть лучше чем ALL, но очень плохо что последний.
А вообще предлагаю упрощать запросы, разбивать на подзапросы и менять структуру или вводить избыточность в таблицы.
EXPLAIN с 1 параметром:
https://www.dropbox.com/s/vq990lw6pccuqo5/2016-07-21_183144.jpg?dl=0
Magistr
А дамп базы можете сделать?
Интересно попробовать, но с нуля моделировать схему лень. Больше подготовительных работ, чем непосредственно процесса решения :)
dma84
Если 35 секунд на 7000 записей - дело не в индексах, ошибка именно в схеме БД.
К примеру, email_1 - email_4 - это уже непонятно, зачем денормализация в этом месте и чем вызвана (но это просто к примеру, потому что про отдельную таблицу автор уже писал, что в последнюю очередь).
без EXPLAIN не понять, скорее всего там где то не юзается индекс и mysql из за этого ворочает миллионами строк, собственно по этому так и долго.
Ну вот поэтому и интересно на схему глянуть - готовую развернуть, чтобы не гадать.
Если там ничего секретного нет, конечно.
Хотя, данные сотрудников, плюс контакты и все такое, не уверен, что можно. Даже самому сомнительно стало :)
Но 35 секунд даже для нескольких миллионов строк много.
К сожаленью, сами понимаете, персональные данные ~7000 сотрудников, увы, не смогу :(
EXPLAIN
https://www.dropbox.com/s/pnqfvct1rxiqaai/2016-07-21_173735.jpg?dl=0
Решений подсказали уже несколько, спасибо всем откликнувшимся. Но тут еще есть чисто теоретический интерес, который я не совсем понимаю.
При Join с 1 емейлом - выполняется 0.1 сек
При Join с 2-мя емейлами - 33сек
При Join с 3-мя емейлами - 33сек
При Join с 4-мя емейлами - 33сек
Если мы он действительно перебил все таблицы, и затык был бы в кол-ве обрабатываемых строк - тогда в зависимости от кол-ва емейлов как-то бы изменялось время выборки, а не было практически одинаковым.
Вот и пытаюсь понять, почему Join по 1 полю - все отлично, по 2 и больше - затык, причем с одинаковой скоростью выборки.
Здравствуйте. В течении дня пытаюсь получить смс для верификации (Украина). Раз 10 уже клацал кнопку выслать код еще раз. Толку 0. У кого-то еще наблюдаются проблемы с получением СМС. Или это только мне так "повезло"?
Кому-то пришли выплаты за последний период? 29-30 сентября? Отправили в среду, в пятницу до сих пор деньги на кошелек не упали..
Кто-то получил последнюю выплату?
В вашем примере - будет распространяться и и на статику.
Если нужно тормознуть только вызов апача, то для этого в секцию http пропишите только это:
А в секцию location / каждого виртуальго хоста добавить это:
location / {limit_req zone=one burst=15;
............................
}
И тогда это правило будет применяться только для динамики в указанных виртуальных хостах.
Спасибо за ответ. У меня возник только 1 вопрос - обязательно ли для каждой локации прописывать вручную
limit_req zone=one burst=15
или достаточно прописать это в секцию - http? Понимаю, что маловероятно, но как говорится, а вдруг? :)
Что за скрипт? ОС? покажите кто-что грузит больше всего при нагрузках бд. Таблицы InnoDB или MyISAM?
top
Без шаловливого робота ВПС-ка держит нагрузку на отлично. ЛА не выше 0,1. Тут проблема именно в создании огромного кол-ва запросов от робота за единицу времени - в моем случае это 40-60 запросов/сек, на протяжении 30-40 секунд, чего достаточно, чтобы положить apache :(
ТС может все же не давать серверу плодить апачи чрезмерно много, тогда и база отваливаться не будет ;)
Я как бы и спрашиваю совета - верно ли мое мышление, либо нужно плясать не в сторону настройки nginx, а в сторону к-ва дочерних процессов апача. К сожалению, опыта у меня не так много в этом вопросе.
Сколько ОЗУ на сервере?
Прошу прощения, поправил первый пост...
на сервере 1 Гб ОЗУ
Начал тестировать данную ПП где-то с месяц назад. (как запасной вариант для основной ПП)
Что имеем: в статистике светится, что ушло в работу 3 заказа. Все, на этом статистика закачивается :) Более детально посмотреть - какой мой %, какова сумма работы и т.д. (как у других ПП) нет.
За все время - суппорт ответил только 1 раз, что в текущей версии интерфейса - не предусмотрено отображения сколько составил мой заработок :) На просьбу подсказать в ручном режиме, через их интерфейс - жду ответа уже неделю (!!!!).
Email, tickets, онлайн чат - везде тишина.
Поэтому вопрос к представителю:
Ваши слова:
Можно узнать, что Вы подразумеваете под детальной статистикой?
А можно как-то откопать моего аккаунт менеджера, и хоть каким-то каналом связи пообщаться с ним?
Пока что опыт работы с Вами - крайне негативный. Отношение к партнерам - отсутствует как таковое :(
у меня как уже год, ПП сайты от них не пашут, думаю чем заменить..
У меня в основном висят их формы, для заказа работы... В принципе платят исправно и четко по графику, но, блин, уже 3-й день все висит намертво :(
Начинаю пробовать официальную ПП от самого заочника.