Сильно варьируется время работы PHP-скрипта

Corvus, скорость всё путём, SSD.

Вопрос остается открытым, как много скрипт открывает этих 1 мб файлов производящих поиск в рамках одного запроса. В среднем.

Вероятно работает файловый кеш...

Данных всего 4гб ?

Пробовали какой-нибудь "ramdrive" ?

Т.е. смонтировать том "в оперативную память" загрузить это всё на него и делать к нему точно такие-же запросы ?

У меня при таком решении буст был даже по сравнению с SSD очень ощутимым.

Тут еще надо смотреть как вы там читаете... не окажется ли так, что чем дальше от начала файла ваши данные, тем дольше выполняется всё это и по факту он не по смещению читает, а действительно перебирает начиная с начала. Это надо проверить. Проверить легко. Допишите в каждый файл 1-10мб в начало(любого мусора), сделайте офсет всего что у вас есть на эти 1-10мб и посмотрите изменится ли время.

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

Я позапускал hdparm многократно, скорость чтения с диска обычно варьируется от 50 до 150 MB/sec. Уже одно это даёт колебание времени работы скрипта в разы.

Скрипт открывает около 3900 файлов по 1 мегабайту, из каждого файла читает 4 байта (по заданному смещению, а оно прямо зависит от широты и долготы точки, то есть в файлах хранятся данные для узлов географической сетки). Таким образом формируется массив исходных данных для работы скрипта.

---------- Добавлено 14.01.2020 в 14:18 ----------

Читаю так:

function ReadRec ($filename, $offset) {

if ( $fp = fopen($filename,'r') ) {

fseek($fp, $offset);

$rec = fread($fp, 4);

//dump($rec);

$newrec = @unpack ('f', $rec);

}

fclose($fp);

return @$newrec[1];

}

---------- Добавлено 14.01.2020 в 14:40 ----------

Спасибо, почитаю на эту тему.

На сервере уже есть tmpfs, осталось разобраться, как её использовать.

Filesystem Size Used Avail Use% Mounted on

/dev/md1 1.4T 833G 472G 64% /

tmpfs 7.7G 0 7.7G 0% /dev/shm

/dev/md0 496M 43M 428M 10% /boot

tmpfs 7.7G 0 7.7G 0% /usr/local/psa/handlers/before-local

tmpfs 7.7G 0 7.7G 0% /usr/local/psa/handlers/before-queue

tmpfs 7.7G 0 7.7G 0% /usr/local/psa/handlers/before-remote

tmpfs 7.7G 0 7.7G 0% /usr/local/psa/handlers/info

tmpfs 7.7G 0 7.7G 0% /usr/local/psa/handlers/spool

---------- Добавлено 14.01.2020 в 14:46 ----------

Проверил. Я временно видоизменил скрипт так, чтобы он читал данные по смещению, заданному принудительно (а не рассчитывал его исходя из широты и долготы). Отличий нет, читаешь с начала файла или из его конца, время выполнения скрипта всё равно случайным образом варьируется от 0.5 до 40 сек.

Это многообещающая инфа, значит читаете сразу из нужного места. Иначе 0.5 не выходило бы.

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

Рамдрайвом я пользовался на клиентских машинах, под дос и виндовз, там всё обстояло именно так.

Нельзя-ли вместо 4000 файлов с узлами сделать 1000500 файлов в каждом которых будет все для одного узла и читать один файл, а не 4000 ? (как вариант по 10-100 штук объединить, да фиг с ним, даже в один файл всё собрать если можно по оффсету читать корректно)

Кстати попробуйте свою функцию на чтение из любого файла длиной скажем 1гб, попробуйте последние байты прочитать и замерьте время. Просто, чтобы убедиться.

_SP_, автор игнорит вопрос про количество читаемых файлов. Файл 1 мб ерунда для одного чтения, такой можно целиком считать и провести все поиски меньше чем за секунду. А вот если таких файлов может быть 4000 под перебор верного, это вот вам и нагрузочка с вариацией 0.5 по 40 секунд. Как по мне, если идёт перебор, то вернее будет все это запихивать в базу данных и работать с ней. Ну и не вижу смысла создавать диск в памяти, зачем, когда можно загнать в память все данные или же использовать memcached с периодическим обновлением данных.

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

Вариации 0.5-40 в принципе "не норма"...

Он ответил, что читает по 4000 файлов.

Отсутствие перебора насколько я понимаю он тоже подтвердил экспериментально, читается именно те 4 байта что надо.

После вторичного запуска при прогретом файловом кеше как я понимаю всё происходит быстро.

Налицо какие-то проблемы на уровне файловой системы и задержек.

Возможно это всё снаружи VPS обрезано как-то.

Яб попробовал с "рамдрайвом". Это быстро, просто и может дать результат.

После ряда мелких улучшений, которые не решали проблему кардинально,

я смонтировал директории (с этими исходными 4000 файлами) как tmpfs,

в итоге теперь скрипт летает как птица, время выполнения устойчиво держится в пределах 0.5 с.

Проблема решена. Всем спасибо за помощь!

ЧТД

К слову сказать... не исключено что у вас с железом проблемы.

Проверьте актуальность бэкапов. Просто от греха.

За какое время теперь исполняется ?

В среднем(0.5?)/мин/макс ?

Спасибо! 0.3 c мин, 0.5 с макс.