hx510b

0. нужно использовать EXPLAIN для анализа причин тормозов https://habr.com/post/211022/
1. LCASE(p.model) = 'ao' - полагаю, индекс не используется - отсюда просадка, лучше изменять регистр в правой части, либо модифицировать данные так, чтобы условия выборки были оптимизированы.
2. заведомо оптимизируемые условия в WHERE:LCASE(p.model) = 'ao' OR LCASE(p.sku) = 'ao'
следует поставить левее, а менее оптимизируемые правее - это поиск подстроки - в самый назад.
суть простая: если какое-то условия сработает - остальные проверяться не будут благодаря OR.
но в данном вопросе это мало влияния оказывает.

Сложное объяснение, но видимо методически правильное есть в статье https://habr.com/company/mailru/blog/335326/
Как показывает практика - LA связан не только с вычислительной нагрузкой на CPU, но зависит и от ввода вывода и других факторов состояния системы.
При определенных обстоятельствах вполне можно наблюдать LA в несколько тысяч, при фактически не загруженных процессорах и обычном количестве и состоянии процессов.

Я для себя LA интерпретирую как комплексный показатель нагрузки на систему.
Упрощенно можно воспринимать как некий эфемерный показатель длины очереди процессов на исполнение - это условное заведомо неверное толкование, но вполне применимое в реальной работе.
Интерпретация значений LA:
Где значения от 0 до 1 указывают на не нагруженную систему близкую к простою.
Значения от 1 до 10 - как умеренно нагруженную систему. Все нормально.
Значения от 10 до 30 - как высоконагруженную систему. Не следует добавлять нагрузку. Можно подумать о поиске оптимизации нагрузки. Оптимизация рекомендуется.
Значения от 30 до 100 - как чрезмерно нагруженную систему, например, причиной может быть большая доля iowait из-за перегрузки - большое количество потоков ввода вывода на одно блочное устройство, аномально медленная работа блочного устройства из-за неисправности, другие подобные причины, связанные с возникновением "бутылочного горлышка" в системе, которое надо расшивать - при таких значениях LA - производительность неэффективная. Оптимизация необходима.
Значения выше 100 - следует воспринимать как аварийное состоянии системы с точки зрения производительности. Нужно принимать меры безотлагательно.
Значения выше 1000 - и дальнейший рост LA ведут к падению ядра, как правило, падение системы происходит в течении ближайших нескольких часов. Требуется экстренная реакция для избежания отказа систем и потери данных.
Границы указаны примерные на основе своего опыта.

Была серия Philips Xenium смартфоны и телефоны с долгим сроком работы. Например, W6610 может жить на заряде неделями. Но телефон морально устарел давно. Если смотреть на более современные модели, то можно смотреть в сторону Xiaomi Redmi 3X или 4X , где X означает усиленную батарею.

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

Судя по:

Error in `/usr/sbin/mysqld': malloc(): memory corruption: 0x00007fcbfc124080

1. сделать копию /var/lib/mysql на другой накопитель

2. Исследуем и решаем:
2.1. вариант1 - битая память - прогнать memtest, может перегрев системы? устраняем или, если обе проблемы не подтверждаются, то идем дальше. Хотя тут похоже сторонний виртуальный сервер. Но проблема может быть.
Если проблема с ОЗУ, то протестировать внутри ОС можно созданием сжатых архивов и проверкой их целостности, в случае проблем с ОЗУ рано или поздно появятся ошибки контрольных сумм.

2.2. вариант2 - либо испорчены файлы данных, и mysql становится плохо из-за кривого кода. файлы могут быть испорчены некорректным завершением работы сервера либо проблемами с блочным устройством:

2018-08-20T05:10:47.359613Z 0 [ERROR] InnoDB: Could not find a valid tablespace file for `kubium/game`. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
2018-08-20T05:10:47.359626Z 0 [Warning] InnoDB: Ignoring tablespace `kubium/game` because it could not be opened.

- это может быть косвенным признаком проблем с файлами.
2.2.1. проверяем состояние блочных устройств smartctl - наличие offline uncorrectable или relocated sectos - могут быть причиной порчи данных - замена накопителя. Для чужого хостинга это недоступно. Можно косвенно проверить чтением блочного устройства /dev/vda
2.2.2. проверяем fsck файловую систему, наличие ошибок в файловой системы может указывать на повреждение содержания файлов БД. чиним и молимся, что важнейшие файлы не были задеты.
2.2.3. проверяем структуру innodb/myisam файлов, для этого используем штатные средства диагностики или вспомогательные утилиты, например "Percona Data Recovery Tool for InnoDB can help recover corrupted or deleted InnoDB tables. https://launchpad.net/percona-data-recovery-tool-f..." если проблемы - пытаемся чинить.
Простой старый способ решения некоторых проблем - это dump базы в sql файл , и импорт заново в базу. старую можно переименовать.
2.2.4. проблема может быть вызвана повреждением файлов индексов, в этом случае пересоздание индексов может все решить.

2.3. вариант3 - похожие проблемы могут наблюдаться при подсовывании двоичных файлов баз от более свежей версии mysql - проверяем эту версию.
Можно попробовать обновить версию mysql или сменить ее на mariadb, возможно некоторые проблемы уже решены.

На машине немного памяти - 1Гб, при исчерпании свободного ОЗУ в системе запускается OOM Killer, который убивает процессы в системе, вполне мог убить процесс mysql прямо посередине критичного изменения файлов БД. Это можно найти в логах.

1. Для контроля неудачных попыток войти есть fail2ban, который банит IP адреса настырных не прошенных гостей и умеет слать об этом письма при необходимости.
2. Для анализа логов и рассылки отчетов есть logwatch, по умолчанию раз в сутки смотрит логи и шлет письмо-отчет местному root, можно перенаправить куда хочется.
3. Для контроля работоспособности сервисов, состояния системы, контроля произвольных точек отказа придуман zabbix, но для одного хоста это будет тяжелым решением.
Возможно, первых двух пунктов для начала хватит.

в ansible есть модуль user, который решает эту задачу.
Почему он не подошел?
https://docs.ansible.com/ansible/2.6/modules/user_...

Можно получить сертификат на другом сервере, хоть на самом дешевом VPS, а потом перенести сертификат на нужную машину внутри сети.
Сертификат никак не привязан к IP адресам, а привязан только в DNS имени.

Если SIM карты нет в устройстве, но модуль сотовой связи включен - то телефон может регистрироваться в сети и соответственно там становиться известным оборудованию оператора. (При этом телефон может на экране показывать что угодно - будто нет связи или показывать шкалу приема - без гарантий).
Регистрация в сети без SIM карты возможна для осуществления экстренных вызовов.
По-моему, это даже требование стандартов сотовой связи.
Это можно проверить - вытащить SIM карту и попробовать позвонить на 112.
Сам по себе сотовый телефон является радиопередатчиком и его работа в сетях связи может обнаруживаться прослушиванием радиоэфира, а местоположение вычисляться по уровню сигнала на базовых станциях (так работает услуга Поиск/Локатор) или пеленговаться по излучению, например, как это показано в фильме про Штирлица.

Попробовать протереть экран лишь слегка увлажненной чистой водой салфеткой. Только не брать магазинные влажные салфетки, а просто смочить чистую ткань кипяченной водой - цель убрать грязь и пятна жира с сенсорного экрана. Либо просто подышать на экран и тереть сухой тканью.
Затем вытереть насухо и дать еще высохнуть несколько минут.
Затем можно проверять.
Многие проблемы у меня так решались.
Ни в коем случае не мочить!

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

Помимо предложений выше. Я бы по оптимизировал where
Условия простые и эффективные с точки зрения индексов подвинуть наверх, далее по возрастанию неэффективности.
Ведь при каждом новом условии объем выборки уменьшается, значит серверу придется делать меньше переборов
потом id in и id not in я бы свел к двум, это будет быстрее, чем несколько раз перекапывать выборку (особенно если она большая или вообще не лезет в память) для сравнения со списком. Т.е. сначала готовим списки, потом один раз сравниваем.
Конечно сам сервер должен быть оптимизирован под такие запросы, чтобы хватало выделенной памяти.

Под такие задачи вполне хватит EXT4
Не надо хранить на одном большом томе миллионы файлов - этим потом управлять сложно - долго копировать и даже долго удалять.
Храните в файлах архивов или образах дисков виртуальных (loop devices) за счет sparse можно получить такую же плотность размещения.

Можно попробовать сделать md raid1, где вторым устройством будет устройство iscsi
md raid1 можно собрать на двух образов дисков, а второй образы положить хоть по NFS, хоть держать на Windows сервере ))

можно сделать по-другому:

Вариант 1: прописать маршрут к этой сети на сервере, чтобы пакеты туда убегали.
я сделал так:
в файл /etc/openvpn/ccd/username добавил команду:
iroute 192.168.102.0 255.255.255.0
при соединении клиента username с openvpn сервером, на сервере поднимается маршрут к этой сети.
Но придется использовать уже две сети - одна для VPN, другая уже для сети за VPN клиентом.

Вариант 2: Прописать на первом компьютере еще один адрес в VPN сети, и прокинуть весь входящий трафик на этот адрес на второй комп с помощью трансляции адресов iptables. А если это касается конкретных сервисов, то сделать TCP-proxy помощью xinetd.