ky0

не пойму на что ругается

Там же красным по фиолетовому написано "permission denied"
Либо нет прав на запуск, либо не от того пользователя запускаете, etc...

Сервер атакуют с кучи китайских, других азиатских ip.

есть чудесные базы для вашей задачи:

• https://lite.ip2location.com/database/ip-country
  
• https://dev.maxmind.com/geoip/geoip2/geolite2

если атака брутфорсом sshd, то вовсе file2ban вам в помощь

у интернет провайдеров в РФ встречаются ip которые определяются как Европейские и т.п.

пруф?

UPD рецепт для ленивых

https://www.ip2location.com/free/visitor-blocker
внизу на странице отличная форма
выбираем страны которые хотим заблокировать, в Output format выбираем linux iptables, и жмем скачать

В типе данных character пустая часть поля заполняется пробелами, они и портят консольный вывод данных
https://www.postgresql.org/docs/9.1/datatype-chara...

Знаки == на конце с большой вероятностью указывают на то, что на финальной стадии это дело пропустили через base64

А не через инструменты яндекса
(На скринах инструменты веб-разработчика фаерфокса, в хроме и сафари аналогичные есть)

Если вы хотите понять почему какой то ресурс грузится медлено у вас на компе, то нахрена вам знать на сколько быстро его загрузили роботы яндекса? Тем более сходу и не поймешь, что именно яндекс считает за время ответа сервера. Либо справку изучать, либо лишь догадываться.

Заблокировано - это вообще не об инете, какая то внутренняя причина отложенного коннекта, в ОС/браузере.

Поиск DNS - на это повлиять вы можете, если найдете более быстрые/близкие DNS сервера, либо организуете свой локальный кэширующий резолвер (например в сети организации)

Соединение - в основном тут задержки из-за криво настроенного сервера, у которого очередь входящих соединений не успевает обработать всех желающих, либо тормознутого инета

Медленная установка TLS - тут фифти фифти, может ваш комп тормоз, может сервер (а может вообще пакеты теряются где то между)

Отправка - если тут задержка при обычном открытии страницы, то к скорости вашего интернета большие вопросы (тут задержка может быть если вы не страницу открываете, а файл на сервер заливаете через POST запрос)

На пункт "ожидание" вы вообще никак не можете повлиять, это чисто серверные нюансы.

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

Если суммарное время всех таймингов менее 300мс (пункт Заблокировано не смотрим), то условно можно считать что сайт, выражаясь языком обывателя, "быстрый"

если чо, то неизвестно проверялке, а не вообще

вообще скрыть не получится, юзай cloudflare - достаточно для начала

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

И проблема тут не в незнании как работать с большими базами данных, а в неумении работать с БД в целом.

Про идею "всем индекс не поставишь" надо сразу забыть. Там где индекс нужен, он должен стоять без вариантов. Другое дело что тупо натыкать индексов по всем полям, по которым идёт поиск - это тоже глупость. Индекс в запросе может использоваться только один, и индексы по второму-третьему полю уже будут бесполезны. Надо анализировать запросы и, возможно, делать составные индексы.

Детсадовский запрос вида like '%...%' - это отдельный ужас. Надо смотреть на полнотекстовый поиск. А лучше вообще его избегать. На крайний случай использовать внешние поисковые сервисы типа эластика. И только не говори что этот лайк у тебя идёт по полю типа джейсон или "через запятую"

Но самый конечно кошмар - это select distinct для фильтров. То есть неумение проектировать бд на самом базовом уровне, непонимание самых начальных принципов реляционных бд, нормализации. Вот с этих принципов и надо начать. В потом уже хвататься за большие объемы. Очевидно, что поля по которым ты собрался делать "distinct" - это должны быть отдельные таблицы, от которых в основной таблице будет просто id. поле размером в 4 байта.

Непонятно, откуда взялись фантазии про гигабайтные индексы, кстати. Большая часть полей в нормальной бд - это не больше десятка байт. То есть индекс - это десятки мегабайт, а не "гигабайты".

В общем, куда лучше бы смотрелись здесь не абстрактные рассуждения про большие объёмы, а конкретный запрос, который "отваливается". С обязательным результатом EXPLAIN

А ответ на абстрактный вопрос "как работать с большими объемами" очень простой: точно так же, как с небольшими. Реляционные бд изначально проектировались под большие размеры. То есть надо просто уметь работать с бд. Читать про реляционную модель, нормализацию, индексы, оптимизацию запросов.

Конкретно для грида надо смотреть в сторону Эластика/Сфинкса. В смысле чтобы не только для полнотекстового поиска, а чтобы все фильтры, которые есть выборке, были забиты в поисковый индекс. И все выборки - через поисковый сервис, а не через прямой запрос к базе

Это старый нюанс веб интерфейса/сервера заббикса, у вас все шаблоны с активными чеками, и агент сам пушит данные в сервер, а чтобы там Availability было зеленым сервер почемуто должен сам хотябы одну метрику спрашивать у аента (нужен тип итема zabbix agent)

Возможно, просто поднимаете vpn сервер в офисе с белым ip и настраиваете vpn клиент на роутере с серым ip и всё готово