В ОС на базе Linux есть сокеты. Перекочевали они из Unix, поэтому называются сокетами unix. Сходу обычно не очевидно, что это такое, особенно когда какой-нибудь php-fpm или mysql может работать по tcp или через сокет. И надо выбрать, как ты хочешь, чтобы он работал.
Сокет — это абстракция, которая позволяет двум процессам взаимодействовать друг с другом. Выглядит эта абстракция как файл на диске. При этом реально на диск ничего не пишется. Файл нужен как точка входа в сокет и инструмент управления доступом. Все данные хранятся и обрабатываются в памяти ядра напрямую. В общем случае такое взаимодействие быстрее того, что проходит через сетевой стек при использовании обычного TCP соединения.
❗️Насчёт производительности важно понимать, что разницу вы заметите только при очень больших нагрузках. Для какого-нибудь среднестатистического веб сервера с сайтами большой разницы не будет. Скорее всего она будет в рамках погрешности измерений. Использовать unix сокет предпочтительно, если доступ к сервису нужен только локальный. Тогда извне гарантированно никто не подключится, в отличите от обычного сетевого доступа, где по недогляду можно открыть доступ к сервису для внешних подключений.
Быстро проверить работу сокета подручными средствами можно с помощью утилиты netcat:
В ответ получите то же самое, что получили бы, если бы обратились к tcp порту через telnet:
Я лично почти всегда использую unix сокет для локальных сервисов, если они его поддерживают.
#linux #system
Сокет — это абстракция, которая позволяет двум процессам взаимодействовать друг с другом. Выглядит эта абстракция как файл на диске. При этом реально на диск ничего не пишется. Файл нужен как точка входа в сокет и инструмент управления доступом. Все данные хранятся и обрабатываются в памяти ядра напрямую. В общем случае такое взаимодействие быстрее того, что проходит через сетевой стек при использовании обычного TCP соединения.
❗️Насчёт производительности важно понимать, что разницу вы заметите только при очень больших нагрузках. Для какого-нибудь среднестатистического веб сервера с сайтами большой разницы не будет. Скорее всего она будет в рамках погрешности измерений. Использовать unix сокет предпочтительно, если доступ к сервису нужен только локальный. Тогда извне гарантированно никто не подключится, в отличите от обычного сетевого доступа, где по недогляду можно открыть доступ к сервису для внешних подключений.
Быстро проверить работу сокета подручными средствами можно с помощью утилиты netcat:
# nc -U /run/mysqld/mysqld.sock
В ответ получите то же самое, что получили бы, если бы обратились к tcp порту через telnet:
# telnet 127.0.0.1 3306
Я лично почти всегда использую unix сокет для локальных сервисов, если они его поддерживают.
#linux #system
В Linux относительно просто назначить выполнение того или иного процесса на заданном количестве ядер процессора. Для этого используется утилита taskset. Она может "сажать" на указанные ядра как запущенный процесс, так и запустить новый с заданными параметрами.
1️⃣ Покажу сразу на примерах. Допустим, у вас есть какой-то процесс, который по умолчанию может занимать ресурсы всех ядер процессора. Допустим, вы хотите разрешить ему работать только на первых двух. Для того, чтобы это сделать, нам необходимо узнать pid процесса:
Выбирайте любой способ, какой больше нравится. Смотрим, какие у нас процессоры и ядра в системе:
Видим четыре CPU с 0 по 3. Посадим наш процесс на первые два ядра:
Где 927 - это pid процесса. Видим, что привязка изменилась с 0-3 на 0,1.
2️⃣ Менять привязку уже запущенных процессов мне кажется не таким полезным, как иметь возможность запустить процесс с заданными параметрами. Это более практичная возможность, для которой нетрудно придумать реальный пример.
Я активно использую архиватор pigz, который умеет жать всеми доступными ядрами. Ему можно задать ограничение на использование ядер, но он будет случайным образом занимать ядра и почти всегда нулевое будет занято. А его желательно оставить свободным для остальных задач. Особенно если вы снимаете дампы СУБД и сразу жмёте в каком-то нагруженном сервере. В таком случае можно явно во время запуска указать pigz, какие ядра использовать.
Для этого нужно запустить программу через taskset, указав ядра, на которых она будет работать. К сожалению, для этого не получится использовать простой список ядер, типа 1,2,3. Нужно использовать bitmask в полном или сокращённом виде. Например, использование только 0-го ядра будет выглядеть вот так:
или просто
Pigz будет жать только одним, нулевым ядром. Я до конца не разобрался, как быстро понять, какая маска тебе нужна. Самый простой способ это узнать, проверить на каком-то работающем процессе. Ему можно задать список ядер не маской, а явно. Допустим, нам нужна запустить архиватор только на 2 и 3 ядре. Для этого назначим, к примеру, эти ядра для htop и посмотрим нужную маску:
Маска
Я взял для примера именно pigz, потому что на нём наглядно видны все настройки. Какие ядра задал, такие он и использует. Для этого достаточно создать небольшой тестовый файл и понаблюдать через htop его поведение:
Список масок, которые имеют отношение к первым 4-м ядрам:
◽
◽
◽
◽
◽
◽
◽
◽
◽
◽
◽
◽
◽
#linux #system
1️⃣ Покажу сразу на примерах. Допустим, у вас есть какой-то процесс, который по умолчанию может занимать ресурсы всех ядер процессора. Допустим, вы хотите разрешить ему работать только на первых двух. Для того, чтобы это сделать, нам необходимо узнать pid процесса:
# ps ax | grep mc
# ps -T -C mc | awk '{print $2}' | grep -E '[0-9]'
# pidof mc
Выбирайте любой способ, какой больше нравится. Смотрим, какие у нас процессоры и ядра в системе:
# lscpu | grep -i CPU\(s\)
# lscpu | grep -i numa
NUMA node(s): 1
NUMA node0 CPU(s): 0-3
Видим четыре CPU с 0 по 3. Посадим наш процесс на первые два ядра:
# taskset -pc 0-1 927
pid 927's current affinity list: 0-3
pid 927's new affinity list: 0,1
Где 927 - это pid процесса. Видим, что привязка изменилась с 0-3 на 0,1.
2️⃣ Менять привязку уже запущенных процессов мне кажется не таким полезным, как иметь возможность запустить процесс с заданными параметрами. Это более практичная возможность, для которой нетрудно придумать реальный пример.
Я активно использую архиватор pigz, который умеет жать всеми доступными ядрами. Ему можно задать ограничение на использование ядер, но он будет случайным образом занимать ядра и почти всегда нулевое будет занято. А его желательно оставить свободным для остальных задач. Особенно если вы снимаете дампы СУБД и сразу жмёте в каком-то нагруженном сервере. В таком случае можно явно во время запуска указать pigz, какие ядра использовать.
Для этого нужно запустить программу через taskset, указав ядра, на которых она будет работать. К сожалению, для этого не получится использовать простой список ядер, типа 1,2,3. Нужно использовать bitmask в полном или сокращённом виде. Например, использование только 0-го ядра будет выглядеть вот так:
# taskset 0x00000001 pigz testfile
или просто
# taskset 1 pigz testfile
Pigz будет жать только одним, нулевым ядром. Я до конца не разобрался, как быстро понять, какая маска тебе нужна. Самый простой способ это узнать, проверить на каком-то работающем процессе. Ему можно задать список ядер не маской, а явно. Допустим, нам нужна запустить архиватор только на 2 и 3 ядре. Для этого назначим, к примеру, эти ядра для htop и посмотрим нужную маску:
# taskset -pc 2-3 `pidof htop`
pid 984's current affinity list: 0-3
pid 984's new affinity list: 2,3
Смотрим маску:
# taskset -p `pidof htop`
pid 984's current affinity mask: c
Маска
c
. Запускаем pigz с этой маской, чтобы он жал только на 2 и 3 ядрах, оставив первые два свободными:# taskset c pigz testfile
Я взял для примера именно pigz, потому что на нём наглядно видны все настройки. Какие ядра задал, такие он и использует. Для этого достаточно создать небольшой тестовый файл и понаблюдать через htop его поведение:
# dd if=/dev/zero of=/tmp/testfile bs=1024 count=2000000
# taskset 6 pigz testfile
Список масок, которые имеют отношение к первым 4-м ядрам:
◽
1
- ядро 0◽
2
- ядро 1◽
3
- ядра 0,1◽
4
- ядро 2◽
5
- ядра 0,2◽
6
- ядра 1,2◽
7
- ядра 1,2,3◽
8
- ядро 3◽
9
- ядра 0,3◽
a
- ядра 1,3◽
b
- ядра 0,1,3◽
с
- ядра 2,3◽
d
- ядра 0,2,3#linux #system