PrAw

ps aux | grep pts

ищете ид процесса (второй столбец) для процесса -bash или что у вас там в качестве шелла по умолчанию:

root     32446  0.2  0.1   7416  3856 pts/0    Ss   11:10   0:00 -bash

убиваете нужный процесс
kill 32446

Ключевой подсказкой будет информация о первой ошибке. Подозреваю, не все файлы или система ищет их не там.
SHIFP+PGUP пролистать - скорей всего сработает.

Вариант - попробовать скачать более старый образ или с другого зеркала.
RUFUS возможно лучше на флэшку запишет

Используйте https://xdebug.org/
и что-то, что умеет дебагать удаленно https://xdebug.org/docs/remote

Настраиваете слушать локальный порт сервера, через SSH пробрасываете порт на свой локальный комп, свою IDE настраиваете цепляться к локальному порту.

А ПОТОМ ПОШАГОВО ДЕБАГАЕТЕ.

Можете заодно спрофилировать скрипт, может сразу видно будет, если отсортировать по времени работы.

Благодаря тому, что порт XDEBUG наружу не торчит, обеспечивается хоть какая-то секьюрность. После завершения работ отключаете это расширение, потому что тормозов оно хоть и немного, но добавляет.

Включая своего внутреннего пророка предсказываю - это программист, долгое время писавший на чем-то типа битрикс, сделал запрос вида:

foreach ($results as $item) query("SELECT * FROM table WHERE ID={$item[id]}");

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

xgu.ru/wiki/qemu-img
https://linux.die.net/man/1/qemu-img
qemu есть под всё. Поддерживает создание и конвертацию много чего
raw, qcow2, qcow, cow, vmdk, cloop, vpc (VHD).
Возможно даже vhdx уже подвезли.

Вообще не с потгресом работаю, но...
Смущает блок (select session from table_2 group by session)
Получается, Вы берёте (и сортируете!) все номера сессий из таблицы 2, в которой 6 421 212 строк, только ради того, чтобы проджоинить с таблицей 1, у которой 4 723 505 строк. Итого сортируем 6 миллионов строк, чтобы отфильтровать 4 миллиона.

Может быть имеет смысл вывернуть запрос наизнанку:

SELECT * FROM table_1 
WHERE primarykey=(SELECT session FROM table_2 WHERE table_2.session=table_1.primarykey LIMIT 1) 
ORDER BY "starttime" DESC LIMIT 20;

В итоге большую сортировку сессий меняем на штучные проверки (по индексу!) для выбираемых строк в соответствии с датой. Еще можно порезать диапазон дат, чтобы работать с недельным/месячным набором, а не всей историей.

https://mva.microsoft.com/
Помнится здесь я встречал лабораторные с подключением к облаку микрософта. Могу ошибаться, возможно это был платный курс, временно выложенный фри.

Ну а по большей части для большинства простых топологий тебе хватит обычного компа на 8 гиг оперативки и фришного Virtual Box. Потребуется много терпения, но работать будет.

Если очень хочется - то по студенческому или просто нахаляву на Azure, Amazon есть немного бесплатных ресурсов, которые можно задействовать для экспериментов.

А лучше всего скиллы поднимает эникейство в местечковой (это важно!) госструктуре. Это:

• археологические изыскания в слоях Win98-Win10
  
• практика с Windows Server 2000-2016
  
• разнообразные пользователи
  
• тренажер тееррпеениияя
  
• тренировка смекалки, как сейчас и без денег решить задачу
  
• планирование, ибо бюджетные деньги надо закладывать заранее
  

Моя личная история - при любом вопросе ответить "сейчас разберемся и попробуем сделать"

Значит, что у тебя файловые операции почти упираются в потолок по пропускной способности носителя. Если всё нравится, то недельку можно не переживать.

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

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

Если пакеты должны уходить на какой-то конкретный ип, то проще всего добавить маршрут на клиенте (или пушить с впн сервера, если он под вашим контролем).

В линуксе команда:
route add -net 192.168.0.0/16 dev eth1

В винде в командной строке:
route ADD ИП_КУДА MASK 255.255.255.255 ШЛЮЗ METRIC 1 IF ИНТЕРФЕЙС
ШЛЮЗ - ип роутера. Можно скомандовать route print до подключения к впн, шлюз в сеть 0.0.0.0 как раз он.
ИНТЕРФЕЙС - номер интерфеса в выдаче route print
пример: 1...........................Software Loopback Interface 1

Можно маршрут в целую подсеть (0-255), подробнее читайте про маску и "адрес сети":
route ADD 12.34.56.0 MASK 255.255.255.0 ШЛЮЗ METRIC 1 IF ИНТЕРФЕЙС

увлекаться докером пока рано для ваших потребностей.
mureevms сказал всё необходимое.
1. DNS сервер если есть - настроить, если нет - поднять
2. добавить DNS записи. указывающие на сервисы
3. Если все сервисы работают только под одним типом вебсервера - не проще там настроить virtual hosts?
https://httpd.apache.org/docs/current/vhosts/examp...
https://tomcat.apache.org/tomcat-8.0-doc/virtual-h...
https://nginx.ru/ru/docs/http/request_processing.html
4. Но проще с видимой стороны оставить только nginx. Классическая схема Nginx на фронтэнд. остальные за ним. причем слушают (Listen) 127.0.0.1:ПО_ВКУСУ

Для этого собственно и добавлялся заголовок Host в протокол HTTP...

грузиться с диска/флэшки и переустановить grub

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

Вариант 1: прямое соединение по ssh с пробросом портов (тогда БД наружу не торчит) и лить запросами в БД
Вариант 2: небольшой веб REST сервис поднять на получателе, куда скидывать хоть через wget пакеты, которые будут обрабатываться и литься в БД.

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

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

tar zcf - tobearchived | ssh user@destination_server_ip 'tar zxf -'
Жмёт со сжатием в tar, отдаёт поток сжатого по ssh, на той стороне запускается tar и распаковывает.
В цепочку можно добавить любой архиватор по вкусу.

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

я так дамп сервака делаю периодически :)

В зависимости от режима, в котором андроида подключаете - он может отдавать как целиком флэшку как обычное съемное устройство, так и эмулировать программно доступ.
Во втором случае - программа-сервер сама решает - какие файлы показывать.
MTP, PTP, USB

Усложнённый вариант, если совсем всё будет плохо - ставьте на телефон какой-нибудь Total Commander с плагином локальной сети и лейте по сети на комп.

Если на входе JPG, почему бы не задействовать MJPEG, который по сути просто склеенные в один файл картинки?
ffmpeg -i %d.jpg all.mjpg

Или просто накидать кадров
ffmpeg -framerate 30 -i %d.jpg -codec copy output.mkv
ffmpeg -framerate 30 -i %d.png -codec copy output.mkv
ffmpeg -framerate 30 -i %d.png -codec copy output.mp4

Уточните, зачем такая странная задача. Можно использовать и Lossless видео-кодеки

если процесс /usr/local/php/bin/php продолжает оставаться в памяти, но занят чем-то не тем - с точки зрения менеджера он вполне работает.

Ищите в коде демона проблемы, добавляйте логирование, чтобы разобраться в причинах или какой-нить watchdog с внешним контролем, чтобы подпереть костылём

1. Убедитесь, что удаленный сервер на ваш комп умеет отдавать одновременно несколько страниц. Например апачевский ab:
ab -c 10 -n 100 http://localhost:8080/
Аккуратно! Сопоставимо с ДоС атакой по нагрузке, убедитесь, что с той стороны будут рады Вас принять. Будет запрашивать в несколько потоков один и тот же урл.

2. Убедитесь, что локальному серверу хватает мощности, чтобы просто отдавать страницы в несколько потоков тем же ab

3. Попробуйте не модулем PHP работать, а вызывать через php.net/manual/ru/function.passthru.php
НЕБЕЗОПАСНО, только теста ради.

4. Попробуйте в тестовом скрипте не стартовать сессии (не уверен, что в этом причина, но бывает блокировка).

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

Гугл "linux open file in kernel mode" оказался достаточно быстр...
https://www.howtoforge.com/reading-files-from-the-...
#include <linux/fs.h> // Needed by filp

Ну как бы лучше начать с другого - а почему каждый конкретный сервис не стартовал?
Виноватым может оказаться, к примеру последовательность запуска сервисов. В момент запуска веб-сервера (утрирую) сеть еще не стартовала, так что он падает. Поменять последовательность запуска и порядок.

Можно взять какоуй-то супервайзер (supervisord?), который уже будет заниматься автоматическим рестартом упавших сервисов (которые он и будет стартовать при запуске).

Nagios/Zabbix умеют мониторить сервисы хоть локального, хоть удаленного компьютера, можно назначить триггеры, которые что-то будут делать при падении.

У консультанта есть вполне честное решение под линукс.

Ключевое отсюда:
Придётся воспользоваться помощью ближайшего к вам партнёра сети КонсультантПлюс. Главное что от него потребуется - бинарник conslin, собранный под соответствующую архитектуру, который согласно прилагаемой к нему инструкции помещают в /usr/local/bin и запускают с правами суперпользователя. Далее откройте cons.exe из-под WINE c ключами /LINUX /REG и дайте представителю партнёра зарегистрировать ваш экземпляр на этом компьютере.

Да, небезопасно, альтернативы
1. поднять VPN, доступ к мускулю снаружи только по впн, не напрямую (резать в iptables)

2. (сам использую) пускать разрабов с пробросом портов по ssh. Себе настроил путти (батник):
putty.exe -ssh user@site.ru -L 3396:localhost:3306
в итоге на компе любой удобный и привычный софт можно использовать, указывая в качестве сервера БД
127.0.0.1:3396, со стороны сервера они выглядят как коннекты с localhost
На сервере завести отдельного юзера с минимальнейшими правами - ему даже входить не обязательно в шелл, только до локального сокета достучаться, плюс настроить авторизацию по сертификату для полного удобства.

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