[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: нагрузка на операционку
Страницы: 1, 2
hurt3
Доброго времени суток.

В общем расклад такой:

Система производит вычисления на основе массивов
скорость обработки как таковая не важна, данные поступают в базу, а не клиенту. Важно что бы не упал скрипт на пол пути заливки в бд.

В php массивы тяжелее своих данных примерно в два -три раза

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

Думал о редиске и мембекеше, но стало понятно что с ними уследить за оперативкой будет еще сложнее. Можно задействовать бд, но для задачи оптимизации это доп решение. Да и смысла нет.
Т.е. логика простая если ты не можешь решить задачу с помощью своего языка кодинга -меняй язык, верно?) Хотя конечно массивы и объекты на пыхе жадные до ресурсов. Можно бы было и полегче реализовать.


И мной был реализован небольшой скрипт -2-3 функции для обработки json массива.
Т.е. если мы получаем массив из json файлика мы не переводим его в массив декодированием? а разбираем как строку.

заливать будем файлик - json строка хранящая 1000 позиций массива.

И вот что получилось, потребление начальное памяти в массиве по отношению к строке = /1,62
пиковые значения примерно идентичны т.е. в масивах пик 13,48 мб
в обработке строкой 8,29
ну и соответственно время в массивах и строках почти равно в некоторых случаях массивы работают дольше мммм.......

И еще кое-что значения массивов можно удалять в ходе их работы, то же можно сделать и со строками, но есть свои нюансы, увеличивается время обработки, если производить операцию сразу расход оперативки увеличивается вдвое.

поэтому скрипт с массивом под конец потребляет 383352 байта а строки 1046976
разница в 2 раза постоянной нагрузки.

Теперь с учетом описанной ситуации и принципов работы оперативки в железе, для приложения на котором я хочу разместить, как можно больше клиентов, у которых будут обрабатываться данные, что лучше использовать:
1) массивы больший объем потребляемой памяти в начале, более высокая пиковая нагрузка, уменьшение расхода оперативки в конце
2) свое решение на строках, меньше объем памяти в начале, меньше пиковая нагрузка, но большее количество затрачиваемой памяти в ходе всей реализации и по идее все-таки должен работать дольше

Верно ли я понимаю, что второй вариант будет более отказоустойчивым и стабильным?

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

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





chee
Я не фига не понял, у тебя слишком большие JSON файлы, насколько большие?

Если читаешь JSON как строку, то выкинь свой велосипед и возьми это https://github.com/salsify/jsonstreamingparser

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
hurt3
chee, а как это установить? через загрузчик в линуксе?

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


Допустим с другого сайта заливается инфа в формате json, информацию нужно разобрать, обработать и сохранить к себе в бд- ну стандартно.

Скрипт ее принимает, и есть несколько решейни как действовать дальше
1) декодировать джейсон и обработать как массив или объект -
потребляет море памяти
2) обработать велосипедом на месте
3) сохранить в файл и получать куски и обработать велосипедом ну или твоим решением
sergeiss
Цитата (hurt3 @ 5.01.2018 - 23:15)
Система производит вычисления на основе массивов

А что за вычисления? Опиши задачу подробнее. Может быть, можно будет найти алгоритм решения более оптимальный, чем использованный тобой. В частности, может быть будет лучше сохранить данные в БД и написать ф

И заодно замечу насчет массивов в ПХП. Во время выполнения скрипта он не чистит память. Точнее говоря, в 5-м ПХП не чистил smile.gif Только по завершении скрипта. Поэтому, если у тебя есть какие-то промежуточные данные, которые ты использовал где-нибудь, потом забыл про них и на какой-нибудь внутренней итерации создаешь заново подобные промежуточные данные, то рекомендация одна. Удаляй любые промежуточные данные сразу же, как только в них пропала необходимость (http://php.net/manual/ru/function.unset.php)! И чем эти данные объёмнее, тем это важнее.

Что касается JSON, то я не понял твое описание. При его использовании, как только из строки переводишь в данные, то тут же в ПХП появляется массив. Если, конечно, ты не обрабатываешь JSON как строку smile.gif Надеюсь, что до такого "велосипеда" ты не добрался.

PS. И откуда данные приходят, тоже пока не понятно.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
hurt3
хм) вот интересный вопрос

использование оперативной памяти при записи инфы в файл
я использую memory_get_peak_usage()
для оценки всплеска использования памяти

при задействовании file_put_contents

получаем

получены данные json памяти затрачено 17014112

данные записаны в новый файл 33677152

если использовать fwrite


получены данные json памяти затрачено 17014112

данные записаны в новый файл 17030064

насколько эти данные точны?
Как я понимаю ghb file_put_contents создается копия данных в вирт памяти и она сохраняется в файлик

при использовании fwrite данные просто дописываются в конец файла
т.е. получается что паяти тратиться лишней не должно, носервер показывает всплеск поедания оперативки

кто врет?




hurt3
приветствую sergeiss

А что за вычисления? Опиши задачу подробнее. Может быть, можно будет найти алгоритм решения более оптимальный, чем использованный тобой. В частности, может быть будет лучше сохранить данные в БД и написать ф

задействован php7
ммм всегда думал что php за собой прибирает

Задача следующая скрипт получает данные json и сохраняет их в базу.
Насколько большой объем данных придет отрегулировать можно, но проблематично.

Поэтому послать могут такой объем, что при декодировании в массив памяти сколько бы ее не было просто не хватит.

Да я думал о сохранении в бд, но вопос сколько будет скушано оперативки при заливке в бд?
Было бы удобно загнать в mysql или партисхед json и обрабатывать его там, базы работают быстрее, но обработка данных и разбор это задача все таки языка.

Т.е. в целом вся проблема сводится к тому, что после того как немалый объем данных получен, нам нужно его сохранить где либо что бы получать порционально и обработать, но само копирование создает копию данных в виртуалке file_put_contents к примеру, что приводит к ее двойному потреблению.

Поэтому да, приходится разбирать json как строку .





hurt3
Как остледить сколько реально памяти затрачено при file_put_contents и fwrite?
sergeiss
Цитата (hurt3 @ 6.01.2018 - 03:01)
ммм всегда думал что php за собой прибирает

По завершении скрипта да, прибирает, однозначно smile.gif

Цитата (hurt3 @ 6.01.2018 - 03:01)
но обработка данных и разбор это задача все таки языка

Не соглашусь. Не надо ставить таких жестких ограничений для себя. Если внутри БД можно сделать более эффективную обработку, то её нужно там делать.

Что касается именно JSON и БД, то в Постгре уже встроена его обработка. Как и, например, в МонгоДБ.

Опять же, если использовать БД, то ты можешь сохранить свои данные в файл, максимально эффективным способом, какой найдешь. И затем дать команду в БД залить этот файл. Вариантов тут может быть много разных.

Цитата (hurt3 @ 6.01.2018 - 03:01)
Поэтому да, приходится разбирать json как строку

Ты считаешь, что сможешь сделать этот разборе более эффективно, чем это сделано в ПХП???

Ну и ты так и не ответил, откуда же приходят данные и почему они именно JSON.


_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
AllesKlar
hurt3
Вот неплохая статья. Там в основном про чтение больших файлов, но смысл одинаков, как не убить сервер средствами php smile.gif

https://www.sitepoint.com/performant-reading-big-files-php/

_____________
[продано копирайтерам]
hurt3
AllesKlar
эх, где же эта статья была раньше... наверно я гуглить разучился.

chee
как этим пользоваться https://github.com/salsify/jsonstreamingparser подключить как модуль php или можно инклудить напрямую в скриптах?

sergeiss

откуда идет json строка не важно как и не важно, что в ней, каталог запчастей для авто или данные из фонда "детская книга" суть то одна.
Необходимо получить данные обработать и сохранить в базу к себе, без задействования большого объема оперативки

Скорее всего реализовать придется так:
1) получить данные curlom и сохранить в файл
2) и файл уже получать построчно
до получения полного элемента массива
3) файлы удаляются кроном


Такой элемент массива можно декодировать и он не будет много весить, точно не 15 мб

я правильно понимаю?

вопрос лишь в одном действительно ли не тратиться куча оперативки при сохранении/чтений файлов через функции вроде fwrite, может быть это не заметно для php происходит?
hurt3
Смешно, поймал себя на мысли, что обработку ошибки о нехватке оперативки по традиции лечу ini_set("memory_limit","256M");
А если и ее не хватает, то докупать памяти у хостера.
sergeiss
Цитата (hurt3 @ 6.01.2018 - 13:34)
откуда идет json строка не важно как и не важно, что в ней, каталог запчастей для авто или данные из фонда "детская книга" суть то одна.

На самом деле это важно. Потому что если ты можешь влиять на эти данные (формирование и отправку), то можешь их запросить не все сразу, а по частям. Ну или не в формате JSON, а в другом виде получать эти данные (например, в формате, готовом для записи в БД). Поэтому и спрашивал.
Если же на данные никак не можешь влиять, то тогда да, придется геморроиться на твоем сервере.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
hurt3
На количество получаемых элементов да -
допустим запросить 50 книг, но какой длинны будет название сказать сложно, можно рассчитать максимальную нагрузку, что и было сделано, но в реальности объем приходящих данных составляет лишь 10% от нее, короче не важно откуда идут данные))))

серж ответь плиз на вопросы
Как отследить сколько реально памяти затрачено при file_put_contents и fwrite?
действительно ли в потоке запрашивается меньше памяти?, просто я наблюдаю потребление 5 лишних мб с панели хостинга, может память пожирается скрыто от php?

Можешь подсказать json потоковый парсер?

И посмотри пожалуйста тему, я понимаю что косо доношу мысли, но все же может разберешься
http://phpforum.su/index.php?showtopic=93109
sergeiss
Насчет использования памяти я реально заморачивался только один раз. Когда делал "демона", для него это было очень важно.
Рассуждая логически, ты прав, что file_put_contents вроде как должен больше памяти использовать.

Ну и насчет "потокого парсера json" я что-то сомневаюсь, что такой возможен. Если бы у тебя данные были изначально разбиты на кусочки, каждый из которых является "самодостаточным", то было бы проще. Но ты считаешь, что это несущественно smile.gif Хотя одно дело, когда один объект JSON на 5000 книг и другое дело, когда 5000 объектов, по одному на каждую книгу. Во втором случае можно парсить по мере поступления данных, не загружая всё полностью.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
hurt3
да но тогда нужно создавать свой велосипед

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

Рассуждая логически, ты прав, что file_put_contents вроде как должен больше памяти использовать.
можно логику в студию?
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.