• Что такое «101»?

    @werwooolf
    Классы кодируются как 3-4 буквы предмета + 3 цифры уровня класса. Сотни в коде примерно соответствуют году обучения в 4-летнем колледже.
    1хх — freshhman (1 курс) — вводные классы
    2xx — sophmore (2 курс)
    3xx — junior (3 курс)
    4xx — senior (4 курс) — специализированные классы повышенного уровня сложности

    Студенту нельзя (или просто не рекоммендуется) брать курсы по номеру выше чем его год обучения.
    Для магистров и аспирантов классы будут соотвественно начинаться с 5хх-9хх.

    Десятки и сотни в номере обозначают разные классы, чаще всего нумерация идет в порядке увеличения сложности, или зависимости классов. Так, например, чтобы взять класс FIN345 («Финансы — средний уровень») нужно обязательно взять FIN302 — «Введение в финансы» и тп. А FIN445 будет наверняка на порядок сложнее чем FIN345.

    Итого, 101 — самый начальный воодный класс в любом предмете, например МАТ101 — введение в математику или BIO101 — введение в биологию.
    Ответ написан
  • Как правильно вычислять vm.dirty_background_bytes и vm.dirty_bytes?

    TaHKucT
    @TaHKucT
    Linux администратор
    У меня ответ больше 10000 символов. Тостер его не пропускает, поэтому разобью его на ответа:

    Я так понимаю что для плавной работы Linux сервера, для плавной записи грязных страниц нужно поправить параметры vm.dirty_background_bytes и vm.dirty_bytes до соразмерных с величинами скорости записи на диск?

    Нет. vm.dirty_background_bytes - сколько байт можно занять под dirty pages до того, как эта память начнем автоматически синхронизироваться на диск. vm.dirty_bytes - сколько всего байт можно занять под dirty pages.

    Например у вас выставлен vm.dirty_background_bytes = 10, vm.dirty_bytes = 30, скорость записи на диск 2 байта в секунду, а скорость записи в ОЗУ 5 байт в секунду (все специально такое маленькое, что бы наглядно было понятно что происходит и не путаться в переводе значений из байт в мегабайты, байт в секунду в мегабиты в секунду и т.п.).
    (Сделаем оговорку что dirty pages работает намного сложнее, чем описанно ниже. Он работает со страницами, а не с байтами, он имеет привязку к конкретным файлам и еще куча нюансов. Ниже очень упрощенный вариант объяснения, что бы получить примерное представление о том, что вообще происходит).

    В Секунду 0 (начало примера) vm.dirty_background_bytes = 0, диск полностью простаивает и ничего не происходит (опустим момент что linux многопоточный и такая ситуация почти нереальна в реальной жизни). Вдруг какой-то процесс начинает писать что-то на диск, фактически он изменяет данные в ОЗУ и помечает страницу как dirty page, фактической записи на диск не происходит (если не происходит вызов fsync, но об этом ниже).
    То есть через секунду, в секунду 1 у нас расклад такой: vm.dirty_background_bytes = 5 (скорость записи в ОЗУ ведь равно 5, дальше будет предполагать что процесс всегда будет писать с этой скоростью, потому что например ему нужно многое записать и все данные к этому уже подготовленны), vm.dirty_bytes = 5 (vm.dirty_bytes - это доступный для dirty page объем памяти, vm.dirty_background_bytes - это часть от vm.dirty_bytes), скорость записи на диск = 0.
    Следующая, 2 секунда: vm.dirty_background_bytes = 10, vm.dirty_bytes = 10, скорость записи на диск = 0.
    Следующая, 3 секунда: vm.dirty_background_bytes = 15, vm.dirty_bytes = 15, скорость записи на диск = 2 (vm.dirty_background_bytes превысил установленные нами условные 10 байт и запускается процесс синхронизации, он выбирает на скорость 2 байта в секунду (как мы условились выше) данные и пишет их на диск) (тут можно спорить в какой именно момент запуститься процесс синхронизации dirty pages на диск, когда vm.dirty_background_bytes будет 9, 10 или 11, но в данном случае этот вопрос не принципиальный).
    Следующая, 4 секунда: vm.dirty_bytes = 18 (+5 записал процесс, -2 синхронизировал процесс синхронизации, итого 15+5-2=18). vm.dirty_background_bytes нас больше не интересует, потому что он синхронизатор уже запустился.
    5 секунда: vm.dirty_bytes = 18
    6 секунда: vm.dirty_bytes = 21
    7 секунда: vm.dirty_bytes = 24
    8 секунда: vm.dirty_bytes = 27
    9 секунда: vm.dirty_bytes = 30
    10 секунда: vm.dirty_bytes = 30 (vm.dirty_bytes уперся в вышеусловленное значение в 30 байт, больше места под dirty page у нас нет, поскольку синхронизирует записывает по 2 байта/с то мы упираемся в 2 байта/с, пока процесс не запишет все свои данные).
    ...
    Энная секунда: (процесс записал все необходимые ему данные): vm.dirty_bytes = 28
    n+1: vm.dirty_bytes = 26 (и т.п.).

    То есть как видно dirty page позволяет нам "сгладить" небольший всплекс на запись, за счет того, что данные, которые нужно записать на диск будут временно храниться в памяти. Причем именно кратковременный всплекс, потому что на долговременном всплекске вы забиваете всю память, отведенную под dirty page и после этого скорость записи падает до скорости работы диска. Очевидно что технология полезная и иногда нужная, но все сильно зависит от ваших парентов нагрузки (именно по этому все совеют разные числа, у кого-то один вариант показывает себя лучше, у кого-то другой.) Увеличивая размер vm.dirty_bytes вы с одной стороны увеличиваете размер пика, который получиться сгладить, с другой увеличиваете объем ОЗУ которое займете под этот пик и время, которое понадобиться на то, что бы разгрести эту ОЗУ.
    При этом я вижу что по дефолту в centos7 выставленны значения vm.dirty_background_ratio = 10 и vm.dirty_ratio = 30 (то есть 30% от всей доступной памяти можно занять под dirty page, запускать синхронизацию если зянято более 10%), vm.dirty_expire_centisecs = 3000 (сбрасывать на диск данные, которые находяться в dirty page больше 30 секунд вне зависимости от того, сколько в данный размер занято под dirty page) и vm.dirty_writeback_centisecs = 500 (синхронизатор должен просыпаться каждые 5 секунд для обработки данных, подподающих под vm.dirty_expire_centisecs).
    На ubuntu (16.04 и 18.04) vm.dirty_ratio = 20, все остальные параметры точно такие-же как у centos.

    Логика тут очень простая: под dirty page память не резервируется. Если она нужна и есть свободная память - она используется (максимум 30% или 20% от всей доступной). Причем доступная память, это не "всего установленно", это именно available память в выводе "free".
    То есть мы получаем "некую автоматическую балансировку" системы по данному параметру в зависимости от "Total RAM - Used RAM", чем доступной памяти больше, тем больше может быть dirty page. Если собираетесь ограничить dirty page в 2-4-8 мегабайт, то хотя бы проведите набор тестов под вашей боевой нагрузкой (не синтетической, а именно боевой) и убедитесь что это хотя-бы не сделает хуже (не снизит производительность). Мой опыт говорит что на моих нагрузках большинство серверов чувствуют себя отлично со значениями по умолчанию.
    Ответ написан
  • Как на linux узнать источник процесса?

    @larrabee
    Посмотреть где лежит исполняемый файл процесса:
    ll /proc/{PID}/exe
    Посмотреть кто его родитель:
    ps -o ppid= -p {PID}
    Ответ написан
  • Как избавиться от ада зависимостей в Debian?

    vaut
    @vaut
    С вашими требованиями дебиан сомнительный выбор.
    Посмотрите в сторону других дистрибутивов.
    Ответ написан
  • Правильно ли я все сделал в iptables?

    EvilMan
    @EvilMan
    Если ставите политику DROP и на OUTPUT, то нужно в неё добавить симметричные разрешающие правила. Например, если у вас есть правило iptables -A INPUT -p tcp --dport 22 -j ACCEPT, то нужно будет и правило iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT. Но обычной практикой является то, что OUTPUT оставляют пустым с политикой ACCEPT.

    Так же обычно добавляют правило типа iptables -A INPUT -i lo -j ACCEPT для того, чтобы разрешить коммуникации между процессами на самом хосте, и правило
    iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
    для того, чтобы разрешить ответные пакеты.

    iptables-save не сохраняет изменения, а только выводит текущий набор правил на стандартный вывод. То, где хранятся настройки iptables зависит от дистрибутива Linux. Например, в Debian-подобных дистрибутивах лучше поставить пакеты netfilter-persistent и iptables-persistent, чтобы можно было загружать настройки файерволла при загрузке.

    В общем, iptables и настройка файерволла требуют хороших знаний по сетям и протоколам, и с наскока их не получится освоить, а только прочитав документацию (благо, есть неплохой перевод iptables tutorial на opennet.ru).
    Ответ написан
  • Как работать с работающим контейнером Docker?

    @Kroid
    В работающий демоном контейнер залезть можно:
    docker exec -it container_name /bin/bash
    Этим мы запустим bash процесс внутри контейнера и подключимся к нему. Выйти из контейнера через команду exit.
    Ответ написан
  • Что будет если доменное имя направить на два DNS с разными настройками?

    несколкьок вариантов
    1. Если вы указали новый нс сервер то старый будет отдавать свою А запись если явно указать NS сервер у которого вы будите запрашивать Адрес. например host -a site.ru ns1.site.ru
    2. Два нс сервера, в таком случае вы будите получать от одного из них информацию, а со второго при отсутствие первого.
    3. Вы указали две А записи, в таком случае они будут выдаваться в 50\50 процентном случае
    Ответ написан
  • Доступ к локальной сети через OpenVPN server. Маршрутизация

    navigator666
    @navigator666 Автор вопроса
    iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 192.168.0.0/24 -j ACCEPT

    и
    iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE

    решили вопрос.
    После этого создал скрипты для восстановления iptables после перезагрузки
    Все работает.
    Ответ написан
  • Настройки iptables для транзита на другой сервер?

    @krosh
    Что-то у Вас каша с правилами. Чтобы порт пробросить в локальную сеть нужно три правила в цепочках: PREROUTING, POSTROUTING и FORWARD.

    Попробуйте почистить все и использовать такие:
    #Пакеты с нужного адреса заворачиваем на компьютер
    iptables -t nat -A PREROUTING -d 22.22.22.22 --dport 9090 -i eth0 -j DNAT --to-destination 196.168.1.200:9090
    
    #Получаем интернет в локалке - это не обязательно, если инет через другой шлюз
    #iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 22.22.22.22
    
    #Меняем адрес источника на локальный
    iptables -t nat -A POSTROUTING -d 196.168.1.200 -p tcp -m tcp --dport 9090 -j SNAT --to-source 196.168.1.100
    
    iptables -A FORWARD -m state --state RELATED,ESTABLISHED -m comment --comment "ALLOW Установленные соединения" -j ACCEPT
    iptables -A FORWARD -p tcp -m tcp --dport 9090 -m comment --comment "ALLOW LAN all 9090" -j ACCEPT


    Цепочка INPUT не влияет на проходящий трафик, можете правило для 9090 от туда удалять.

    Если у Debian есть .100, то не вижу смысла ему еще выдавать какой-то.
    Ответ написан