Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (26)

Лучшие ответы пользователя

Все ответы (35)
  • Почему CLOSE_WAIT зависают и вешают веб-сервер?

    @hx510b
    Можно донастроить TCP стек, чтобы уменьшить время удержания открытых сокетов:
    echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout  # освобождать через 5 секунд
    echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle  # включить утилизацию

    Изменить параметрые nginx:
    worker_processes auto;
    - количество процессов по количеству ядер CPU или auto
    events {
           worker_connections 10000;
           multi_accept on;
    }

    - worker_connections сколько надо держать соединений на один процесс, т.е.
    worker_processes * worker_connections = сколько всего соединений надо обрабатывать.
    multi_accept on - процесс будет пытаться сразу брать все новые соединения, а не по одному.
    worker_rlimit_nofile 200000;
    - т.е. если хотим 100000 соединений, то пишем 200000

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

    Еще по теме:
    https://habr.com/post/198982/ - Ускоряем Nginx за 5 минут
    https://romantelychko.com/blog/1300/ - Настройка Linux для высоконагруженных проектов и защиты от DDoS
    Ответ написан
  • С чего начать изучение для Настройки VPN сервера?

    @hx510b
    Рекомендую настраивать OpenVPN, это стандарт де-факто в индустрии, поддерживается практически всеми операционными системами.
    Надо найти любую инструкцию как настроить VPN на основе OpenVPN и выполнить ее и получить работоспособную систему, затем менять ее под свои потребности.
    Ссылки: https://habr.com/post/233971/ или https://habr.com/post/188474/
    Ответ написан
  • Где целесообразно использовать LXC/LXD?

    @hx510b
    LXC удобно использовать для отвязки от ОС хоста, как современный аналог OpenVZ (OpenVZ устарел, т.к. не поддерживается новыми ядрами и дистрибутивами). Мы использовали LXC для виртуализации Linux сервисов. LXC значительно эффективнее расходует ресурсы, чем KVM.
    LXC внутри больше похож на виртуальную машину, чем Docker. В LXC почти все привычные инструменты работают как обычно. Но изолированно от хост системы. Можно ставить пакеты, менять настройки etc, запускать демоны и использовать стандартные инструменты Linux среды и т.д. Для LXC можно подтянуть специфичные для дистрибутивов шаблоны. Например, на хосте с Ubuntu поднять гостя с Centos. При желании гостя можно держать на виртуальном диске.

    Еще про разницу между LXC и docker написано тут: https://vps.ua/blog/docker-and-linux-containers/
    Ответ написан
  • Как обеспечивается совершенно бесперебойная работа сервера?

    @hx510b
    Вариант №1 - создание отказоустойчивого кластера - два физических сервера работают в паре, при этом один сервер выполняет работу, а второй сервер работает в резерве, при этом получает актуальные копию данных с первого сервера, делается разными инструментами. В случае гибели первого сервера, второй берет нагрузку на себя.
    Вариант №2 - применим для веб-сайтов - пользовательские запросы направляются на сервера по определенным правилам на несколько серверов, в случае выход из строя одного из серверов - нагрузка вырастает на оставшиеся.
    Вариант №3 - географически разнесенные дубликаты сервисов - самый надежный вариант, но кластер на длинных расстояниях сделать очень сложно - возникают проблемы с пропускной способностью, задержкой передачи и временными перерывами связи - не все протоколы, работающие в локальной сети способны справиться с этой проблемой.
    В целом задача решается с применением известных решений с учетом специфики решаемой задачи и существующей архитектуры сервиса.
    Простого решения - панацеи от всех проблем нет.
    Ответ написан
  • Как исправить ошибку: Lost connection to MySQL server during query?

    @hx510b
    Судя по:
    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 прямо посередине критичного изменения файлов БД. Это можно найти в логах.
    Ответ написан