Скорость работы MySql

[Andreika]

Maxxon
ну и чего такого в статистике имеется, что не укладывается в сумму, среднее арифметическое и минимум/максимум? какие возможности именно пхп используются, что нельзя это сделать в SQL ?

 

[Wicked]

[offtop]Бойся телепатов Они уже трудятся над раскрытием твоей конфиденциальной информации...[/offtop]

 

[Maxxon]

Потому что я грешу на настройки MySql, что памяти 256 метров на сервере, и ей наверняка можно выделить побольше, чем в данный момент настроено, чтобы соображала быстрее.
Именно на этот вопрос мне бы хотелось получить ответ.
Как, где, и будет ли прирост в скорости.
my.cnf или какие-то другие конфигурационные файлы в linux?

Если MySql по дефолту работает с памятью меньше мегабайта, судя по настройкам? Я поставил 16 метров и прироста не заметил. Неужели здесь поможет только нагрузка арифметикой самой базы? Желания переписывать весь скрипт пока нету ...

 

[Фанат]

Именно на этот вопрос мне бы хотелось получить ответ.

нет проблем.
читай, настраивай.

тебе нужна подсказка, где почитать, или ты даже этого самостоятельно не сообразишь?

 

[Maxxon]

Фанат
Самостоятельно я нашел faq по "тонкой настройке" mysql, но он мало помог в результате. Ты мне скажи точно, это реально даст прирост в скорости или нет? Или мне настраивать себя на переписывание скрипта заново?

Сорри, за тупые вопросы

 

[Andreika]

по дефолту работает с памятью меньше мегабайта
т.е. не компе с 1мб оперативки?

Я поставил 16 метров и прироста не заметил
где чего поставил?

ты же заставляешь mysql вывалить тебе всю базу в скрипт, но хочешь быстрее

 

[Фанат]

ТОЧНО
ТЕБЕ
НИКТО
НЕ СКАЖЕТ

потому что никто не знает, ЧТО у тебя тормозит, и тормозит ли ВООБЩЕ

короче, надо заканчивать это плодотворную дискуссию.

 

[Maxxon]

Дык чтож с ним сделать-то?
Кто сможет дать конкретный ответ что делать с настройками?

-~{}~ 01.03.06 15:38:

Ок. Заканчиваем.

 

[Фанат]

возьми все запросы, которые у тебя выполняются в твоём скрипте
(я ОЧЕНЬ надеюсь, что у тебя там нет запросов в цикле)

и выполни их все в консоли.
там тебе покажет такие маленькие цыферки после выполнения каждого.
это время.
если время выполнения какого-то запроса сильно большое - десятыве доли секунды или больше - то тогда надо что-то оптимизировать (скорее всего - запрос).
а если время всех запросов минимальное, то тогда наджо не базу оптимизировать, а вырвать руки тому человеку, который писал скрипт, и вставить туда, откуда они у него растут.

я доступно расписал алгоритм?

 

[PartizaneN]

Или просто засеки время до резалта и после резалта и сложи его всё... А лучше выведи еще весь список своих квэрей...

У меня это имеет след вид:
0.030209064483643 select .......... 0.00071310997009277
0.039928197860718 select .......... 0.00097513198852539
0.040824174880981 select............0.00023484230041504
0.041381120681763 select............0.00020313262939453

и в конце еще выведи общее время выполнения скрипта....

 

[Maxxon]

Ок. Спасибо всем!
Буду пробовать.

 

[Сергей Тарасов]

Резюмируя вышесказанное подчеркну то, что говорят здесь умные люди:

1. Необходимо определить место в твоем комплексе, где работа действительно "тормозит". Советую просто прогнать скрипт в дебагере. При 10 минутной задержке ты точно увидишь где то самое узкое место.
Скорее всего тормозит именно обработка PHP, в противном случае неправильно спроектирована структура БД

2. Не делать вещей типа... выборка всех строк и сохранение их в массив, а потом обработка в PHP - он не приспособлен к ворочанию больших объемов данных (в том числе и чисел) - для этого и нужен сервер БД

3. Как можно больше операций засунуть в SQL-запрос
4. Минимизировать кол-во строк/столбцов в ответе SQL - для того чтобы снизить нагрузку на канал между Apache и MySQL - как тебе известно это IPC(сокеты или каналы), передача больших массивов данных через них плохо сказывается на произвидительности

Все остальное, конечно, надо смотреть...
Удачи!

3

 

[MadMike]

Автор оригинала: Сергей Тарасов
2. Не делать вещей типа... выборка всех строк и сохранение их в массив, а потом обработка в PHP - он не приспособлен к ворочанию больших объемов данных (в том числе и чисел) - для этого и нужен сервер БД

3. Как можно больше операций засунуть в SQL-запрос

А вот позволю себе с этим не согласиться
При больших нагрузках бывает гораздо выгоднее перенести все вычисления в php, чтобы уменьшить нагрузку на базу. Думаю, товарищи из мамбы меня поддержат

 

[Сергей Тарасов]

Хм... Это извечная, я бы сказал, дискуссия...

По поводу нагрузок - что в лоб что по лбу... Либо мы нагружаем Apache либо MySQL. И то и другое - процессы системы.

Могу привести аргументы в защиту своих утверждений... Дело в том, что для обработки больших массивов данных в СУБД применяются СПЕЦИАЛЬНЫЕ алгоритмы и СПЕЦИАЛЬНЫЕ методы хранения данных, над которыми бьются лучшие умы... PHP-скрипты пользователей обычно этим не отличаются...

 

[MadMike]

ой, только не надо мне объяснять
И причем здесь апач?
Возьмем оффлайновый скрипт. Селект по InnoDB'шной таблице, в которой 100-200 миллионов записей такого типа id | ts. Цель - сгруппировать данные по ts и положить в другое место:
select count(*), ts from table group by ts
за приемлемое время не выполнится. Лимиты не помогут. А вот последовательные
select id, ts from table limit 0,50000
с группировкой php-скриптом - отлично отработается.

А лучшие умы не могут предусмотреть всего, тем более, что мы вроде тоже не идиоты

 

[Сергей Тарасов]

Весь вопрос заключается только в том, насколько ты владеешь SQL и насколько правильно спроектирована БД

 

[master_x]

MadMike
я не верю в то, что ты сказал, подтверди свои высказывания тестами и результатами профилирования.

 

[Сергей Тарасов]

Итак у тебя 200 млн записей
Тогда представь сколько памяти и времени у тебя сожрет 4000 таких запросов???
select id, ts from table limit 0,50000
С master_x полностью согласен.

 

[moxnatiy]

master_x
Сергей Тарасов

господа, тут не в "верю , не верю" играют.
если вам интересно попробуйте протестите.

 

[Фанат]

moxnatiy
хорошая позиция.
писать всякий бред, а если кому-то не нравится, то пусть сам тестирует.