Добавил ещё один порт, работает! Спасибо!!!
Мне нужно, чтобы с локального компа (где 22 порт запрещён провайдером домашнего интернета) трафик шёл по порту 8081, а уже на сервере перебрасывался с 8081 на 22. На сервере-то никаких запретов нет, всё можно настроить как надо.
Спасибо! Просто хотелось бы и на 22 порту шелл оставить (когда вхожу из нормальных мест, где этот порт не закрыт),
и новый порт добавить.
Вторая сторона проблемы в том, что дома комп не линуксовый, а виндовый, то есть из командной строки ssh не запустишь,
надо колдовать с настройками Putty.
Спасибо! 0.3 c мин, 0.5 с макс.
После ряда мелких улучшений, которые не решали проблему кардинально,
я смонтировал директории (с этими исходными 4000 файлами) как tmpfs,
в итоге теперь скрипт летает как птица, время выполнения устойчиво держится в пределах 0.5 с.
Проблема решена. Всем спасибо за помощь!
Я позапускал 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 сек.
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.44716 s, 742 MB/s
hdparm выдаёт:
/dev/sda
Timing cached reads: 3590 MB in 2.00 seconds = 1795.36 MB/sec
Timing buffered disk reads: 290 MB in 3.02 seconds = 96.08 MB/sec
/dev/sdb:
Timing cached reads: 3580 MB in 2.00 seconds = 1789.78 MB/sec
Timing buffered disk reads: 474 MB in 3.00 seconds = 157.90 MB/sec
1. У меня не определение геоположения, а геопривязанные данные - физические параметры атмосферы для разных точек планеты, для разных высот и разных моментов времени.
2. Читаю из каждого файла одно число, 4 байта, по заданному смещению (смещение вычисляется по широте и долготе точки)
примерно так:
if ( $fp = fopen($filename,'r-') ) {
return @$newrec[1];---------- Добавлено 11.01.2020 в 19:36 ----------
1. 4150 файлов, 4,3 Гб, каждый файл около 1 Мб.
2, 3. Да. Если второй раз выполнить точно такой же запрос (с той же широтой и долготой), данные возвращаются мгновенно.
А если немного изменить широту/долготу, тут уже 50:50, или 0.5 сек, или 30-40 сек.---------- Добавлено 11.01.2020 в 19:41 ----------
Я думал уже об этом. Сделать что-то вроде демона, который будет держать все эти файлы (несколько гигабайт) в памяти и считывать нужные данные прямо оттуда.
Но у меня подобный проект (с чтением данных из большого количества файлов) работает уже 8 лет на другом сервере, VPS, с гораздо более скромными системными параметрами. Скрипты устойчиво выполняются пусть не за 0.5 с, так за 2-3 с.
На выделенном сервере, как я ожидал, всё будет летать. Но нет - ситуация совсем другая и грустная.
Такое впечатление, что что-то с настройками файловой системы.
У меня тоже такое подозрение. Попадались статьи на тему, что если индексы не нужны (априори известно местонахождение нужных данных - в каком файле и по какому смещению, а это как раз мой случай), то прямая работа с файлами априори быстрее, чем любая БД.
Пинги нормальные, интернет тоже. Время выполнения скрипта я подсчитываю в самом скрипте, то есть без учёта затрат на передачу данных по сети. Если скрипт вызывать не через веб, а из командной строки через шелл, работает он так же неустойчиво.---------- Добавлено 10.01.2020 в 16:25 ----------
Да, я так делал. Отображал и время выполнения отдельных операций, и затраты памяти.
В том-то и проблема, что при одном запуске скрипта каждая операция чтения файла занимает, условно, 0.001 секунды и общее время работы скрипта 0.5 секунд, а в другом каждая операция чтения 0.1 секунды и общее время 40-50 секунд.
Вычисления в скрипте выполняются буквально за 0.2 секунды. То есть основное время уходит на чтение файлов, оно-то и занимает очень много времени.---------- Добавлено 10.01.2020 в 16:29 ----------
Спасибо! Попробую то, что Вы сказали.
Как думаете, есть ли смысл помещатьисходные данные в БД? Их общий размер около 9 Гб, обновляются они несколько раз в сутки. Будет ли выигрыш по времени чтения, и стоит ли игра свеч, ведь залив в БД такого объёма будет идти, вероятно, весьма долго.
Просто зная широту и долготу точки, я однозначно знаю, по какому смещению читать данные из файлов. Казалось бы, в таком случае чтение из файлов должно работать быстрее, чем чтение из БД?---------- Добавлено 10.01.2020 в 16:32 ----------
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 125436
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 500000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 50000
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
По идее этого должно быть достаточно?
