Количество соединения (соединений) SSH на единственной машине Linux

Необходимо знать о возможностях каждой части стека. Какие диски составляют файловую систему для доли NFS? SAS? SATA? SSD? Какой тип и размер и скорость об/мин каждого? вращательная задержка? Действительно ли это - диск 4k? ZFS оптимизирован для 512-байтовых дисков и там известен проблемы с производительностью с помощью нового "усовершенствованного формата" диски.

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

От просто перспективы устройства хранения данных, эти вопросы будут влиять, как быстрые данные могут быть записаны в и считаны с внутренних дисков. Например, скажем, Ваша доля NFS поступала из файловой системы на диске SATA на 7 200 об/мин 1 ТБ, и что Ваш размер рабочей нагрузки составляет 64 КБ и главным образом случаен.

Random Workload, 64 KB IO size
--------------------------------------------------------------------------------
Average Read Seek Time:        8.4 ms
Average Write Seek Time:       8.9 ms
Rotational latency:           .120 ms
Average Latency:             4.166 ms
Average Read Service Time:  12.566 ms
Average Write Service Time: 13.066 ms
--------------------------------------------------------------------------------
Best Case Read IOPs:           79.000
Best Case Write IOPs:          76.000
--------------------------------------------------------------------------------
Best Case Read Throughput:  4.937 MB/s
Best Case Write Throughput: 4.750 MB/s
--------------------------------------------------------------------------------
Real World Read IOPs:         55.300
Real World Write IOPs:        53.200
--------------------------------------------------------------------------------
Real World Read Throughput:  3.325 MB/s
Real World Write Throughput: 3.325 MB/s
--------------------------------------------------------------------------------

Это даст Вам общее представление о производительности реального мира, которую можно ожидать получать от отдельного диска в определенном размере рабочей нагрузки.

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

После того как Вы понимаете производительность своего устройства хранения данных бэкенда, затем можно ли начать смотреть на дополнительные издержки, созданные NFS (это v3? v4? tcp? udp?), или SSH (какой алгоритм шифрования Вы используете? можно использовать более легкий алгоритм как arcfour для улучшения производительности), или сама сеть. У Вас есть дешевка 1GbE NIC? или качество сервера более высокого уровня NIC? Вы совместно используете это nic между многочисленными услугами? что-либо еще генерирует трафик в Вашей сети? Как насчет перегрузки сети, коллизий или высоких уровней повторной передачи?

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

Теперь, числа выше являются своего рода худшим вариантом развития событий, правильно? 100%-я случайная синхронная рабочая нагрузка. Если у Вас есть последовательная рабочая нагрузка, или можно повысить размер рабочей нагрузки IO, можно существенно повысить производительность. Например, если можно ударить размер IO к 128k, Вы удвоите свою производительность, и в зависимости от Вашего клиента NFS, Вы можете устанавливать rsize и wsize, к различным настройкам к проведению испытаний. Существует после всего точка убывающей доходности.

И если у Вас есть несколько дисков в зеркале или RAID, необходимо будет скорректировать числа для этого.

Производительность диска Реального мира почти никогда не, что печатается на стороне поля, что диск вошел.

12
21.09.2018, 15:58
3 ответа

Да, можно ограничить количество одновременных сеансов входа в систему, хотя большинство дистрибутивов Linux не налагают такие ограничения в своих настройках по умолчанию.

Linux по своей природе является правильной многопользовательской системой, и обычно у вас не должно возникнуть проблем с одновременным использованием нескольких сеансов SSH для одного и того же пользователя.

Сервер SSH может устанавливать такие ограничения с помощью параметра MaxSessions в файле конфигурации. С помощью PAM вы можете устанавливать такие ограничения, а также другие, на которые уже указывалось.

8
29.04.2021, 00:40

Вероятно, у вас есть ограничения, установленные в /etc/security/limits.conf , например,

root hard maxlogins 1

Измените предел (1) на что-то выше, если нужно.

8
29.04.2021, 00:40

Попытка убедить автономный демон sshd ограничить количество сеансов чревата лазейками. Такие вещи, как MaxSessions , ограничивают что-то иное, чем то, о чем говорит OP. И sshd игнорирует limits.conf в Linux (аналогично login.conf во FreeBSD), если вы не настроите все правильно для маршрутизации всех входящих сеансов через PAM и не используете соответствующий настроил модуль PAM, чтобы сначала проверить такие вещи, как limits.conf. Трудно заставить его работать правильно.

С другой стороны, если вы не запускаете sshd как автономный демон, вы можете использовать ограничивающие функции в «вещи», которая порождает sshd по запросу.

Например, inetd и xinetd имеют функцию ограничения соединений (которая обычно по умолчанию не устанавливает никаких ограничений на количество разветвленных дочерних элементов). В классическом inetd он называется «max-child». В xinetd найдите ручку конфигурации экземпляров . Например, стиль inetd :

ssh  stream  tcp  nowait/3  root  /usr/sbin/sshd  sshd -i -4

Это ограничивает количество одновременных ssh-соединений до 3.

Для тех, кто так склонен, systemd может заменить функцию ] inetd , и я считаю, что есть способ ограничить количество экземпляров службы. Упражнение оставлено читателю (или добавьте комментарий с подробностями!).

3
29.04.2021, 00:40

Теги

Похожие вопросы