Здравствуйте. При работе с очень большими объёмами данных типа Array(), при заполнении 2,5 Гб и более, оперативы скриптом, возникает некий тормоз... система периодически подвисает И чем больше данных, тем дольше паузы Помогите разобраться: что происходит, и как с этим бороться?
математические возможности и скорости - не самая сильная сторона пхп. тем более с такими объемами. может лучше критичные места вычислять не на пхп, а на чемто пошустрее. типа с++ ?
Тут даже не в "шустрее" дело, а в возможности обрабатывать данные за пределами возможностей оперативы. С другим языком можно добиться некоторого эффекта, но это только отодвинет момент когда всё опять упрется. Суперкомпьютера в распоряжении автора нет, я так понимаю. Решать проблему надо алгоритмически.
кстати. обычные массивы в пхп довольно жирные. но есть альтернатива. например http://php.net/manual/ru/class.splfixedarray я незнаю специфики ваших данных, но посмотрите, может поможет
А вообще для начала надо иметь диагноз. Сколько памяти доступно PHP? Т.е. сколько показывает phpinfo в параметре memory_limit ? Сколько памяти расходуется скриптом в этой задаче? Т.е. сколько покажет memory_get_peak_usage() в конце работы?
это не то, т.к. мы не имеем массивов фиксированной длины, а постоянно ковертить туда-сюда тоже не выход Добавлено спустя 50 секунд: memory_limit 80 GB
это phpinfo показал или это написано в .ini — две большие разницы. и что там с пиковым расходом памяти? Добавлено спустя 2 минуты 21 секунду: какова вычислительная сложность алгоритма? если объем вычислений растет как квадрат от объема данных, то вы обречены на страдания ))) Добавлено спустя 1 минуту 59 секунд: если отвечать на заголовок вашей темы буквально, то резервируйте память сразу, а не по одной ячейке. это снизит накладные расходы.
80Gb это я установил) и, ДА , объём вычислений и данных растёт как квадрат, ато и куб -------------------------- а, например, если написать на СИ(под линукс), разве СИ и ПХП не похожи?
профилируйте на что именно тратится бОльшая часть времени. Код (PHP): $t = microtime(true); // ... долгая операция ... printf('прошло %.4f', microtime(true) - $t); пробуйте холостые прогоны, например оставьте только рост массива, без вычислений. потом наоборот все вычисления, но без резервирования памяти (реальный результат в этот момент не важен) — на что уйдет больше времени? оптимизируйте только самые затратные вещи. p.s. так и не ответил на мой вопрос. ну и фиг с тобой.
сколько реально выделено памяти? напишешь в ini 1024 Gb и пыха реально выделить тебе 512 Mb. реальность сильнее хотелок. сколько показывает phpinfo? сколько памяти тратит скрипт — memory_get_peak_usage ?
phpinfo(); показывает столько, сколько выделено в настройках PHP(webmin) скрипт расчитан на работу со всем объёмом памяти, все расходы смотрю через системный монитор. по анализу работы, в следствие упрощения и урезки, делаем вывод: создаётся впечатление, что при добавлении элементов массива, в какой-то момент ПХП создаёт новый массив и добавляет значения в него... чем больше данных в массиве, тем дольше задержки
не знаю что такое "вебмин", будем считать что это phpinfo ))) memory_get_peak_usage() — это функция, которую надо вставить в скрипт и посмотреть результат. она скажет сколько реально потратил скрипт из доступного. конечно, динамическое выделение памяти так и работает — сначала тебе дается кусок с небольшим запасом. если его не хватает, выделаяется новый кусок в два раза больше и все данные переносятся в него и т.д. я же писал: "резервируйте память сразу, а не по одной ячейке. это снизит накладные расходы." но без профилирования можно только гадать что именно тормозит. меряй!!!
видимо тормозит сам способ выделения памяти. с этим не поспорить... ( но как заранее выделить массив, если не известен размер результирующего? ведь он может быть "в квадрате или кубе" от размера исходного (7-го прядка)....
джава по крайней мере жестко типизированный язык. вы исходники пхп-машины читали? она ориентирована на генерацию трафика в вебе. быструю (ну тут сравнивать не с чем, имхо) и простую (тут скорее на деплой нужно смотреть. язык простой, кросплатформенный. написал и забыл. никаких костылей с препроцессорами, компиляцией и тому подобное). вычислять математические алгоритмы нужно явно не на пхп. идеально, имхо - с++. сами продумаете и оптимизируете алгоритм еще на стадии разработки.