Команды Linux, для работы с файлами
Эти команды используются для обработки файлов и каталогов.
33. ls
Очень простая, но мощная команда, используемая для отображения файлов и каталогов. По умолчанию команда ls отобразит содержимое текущего каталога.
34. pwd
Linux pwd — это команда для показывает имя текущего рабочего каталога. Когда мы теряемся в каталогах, мы всегда можем показать, где мы находимся.
Пример ример ниже:
35. mkdir
В Linux мы можем использовать команду mkdir для создания каталога.
По умолчанию, запустив mkdir без какой-либо опции, он создаст каталог в текущем каталоге.
36. cat
Мы используем команду cat в основном для просмотра содержимого, объединения и перенаправления выходных файлов. Самый простой способ использовать cat— это просто ввести » имя_файла cat’.
В следующих примерах команды cat отобразится имя дистрибутива Linux и версия, которая в настоящее время установлена на сервере.
37. rm
Когда файл больше не нужен, мы можем удалить его, чтобы сэкономить место. В системе Linux мы можем использовать для этого команду rm.
38. cp
Команда Cp используется в Linux для создания копий файлов и каталогов.
Следующая команда скопирует файл ‘myfile.txt» из текущего каталога в «/home/linkedin/office«.
39. mv
Когда вы хотите переместить файлы из одного места в другое и не хотите их дублировать, требуется использовать команду mv. Подробнее можно прочитать ЗДЕСЬ.
40.cd
Команда Cd используется для изменения текущего рабочего каталога пользователя в Linux и других Unix-подобных операционных системах.
41. Ln
Символическая ссылка или программная ссылка — это особый тип файла, который содержит ссылку, указывающую на другой файл или каталог. Команда ln используется для создания символических ссылок.
Команда Ln использует следующий синтаксис:
42. touch
Команда Touch используется в Linux для изменения времени доступа к файлам и их модификации. Мы можем использовать команду touch для создания пустого файла.
44. head
Команда head используется для печати первых нескольких строк текстового файла. По умолчанию команда head выводит первые 10 строк каждого файла.
45. tail
Как вы, возможно, знаете, команда cat используется для отображения всего содержимого файла с помощью стандартного ввода. Но в некоторых случаях нам приходится отображать часть файла. По умолчанию команда tail отображает последние десять строк.
46. gpg
GPG — это инструмент, используемый в Linux для безопасной связи. Он использует комбинацию двух ключей (криптография с симметричным ключом и открытым ключом) для шифрования файлов.
50. uniq
Uniq — это инструмент командной строки, используемый для создания отчетов и фильтрации повторяющихся строк из файла.
53. tee
Команда Linux tee используется для связывания и перенаправления задач, вы можете перенаправить вывод и/или ошибки в файл, и он не будет отображаться в терминале.
54. tr
Команда tr (translate) используется в Linux в основном для перевода и удаления символов. Его можно использовать для преобразования прописных букв в строчные, сжатия повторяющихся символов и удаления символов.
With systemd
Hierarchy
Current cgroup hierarchy can be seen with or command.
$ systemctl status
● myarchlinux
State: running
Jobs: 0 queued
Failed: 0 units
Since: Wed 2019-12-04 22:16:28 UTC; 1 day 4h ago
CGroup: /
├─user.slice
│ └─user-1000.slice
│ ├─[email protected]
│ │ ├─gnome-shell-wayland.service
│ │ │ ├─ 1129 /usr/bin/gnome-shell
│ │ ├─gnome-terminal-server.service
│ │ │ ├─33519 /usr/lib/gnome-terminal-server
│ │ │ ├─37298 fish
│ │ │ └─39239 systemctl status
│ │ ├─init.scope
│ │ │ ├─1066 /usr/lib/systemd/systemd --user
│ │ │ └─1067 (sd-pam)
│ └─session-2.scope
│ ├─1053 gdm-session-worker [pam/gdm-password]
│ ├─1078 /usr/bin/gnome-keyring-daemon --daemonize --login
│ ├─1082 /usr/lib/gdm-wayland-session /usr/bin/gnome-session
│ ├─1086 /usr/lib/gnome-session-binary
│ └─3514 /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh
├─init.scope
│ └─1 /sbin/init
└─system.slice
├─systemd-udevd.service
│ └─285 /usr/lib/systemd/systemd-udevd
├─systemd-journald.service
│ └─272 /usr/lib/systemd/systemd-journald
├─NetworkManager.service
│ └─656 /usr/bin/NetworkManager --no-daemon
├─gdm.service
│ └─668 /usr/bin/gdm
└─systemd-logind.service
└─654 /usr/lib/systemd/systemd-logind
Find cgroup of a process
The cgroup name of a process can be found in .
For example, the cgroup of the shell:
$ cat /proc/self/cgroup
0::/user.slice/user-1000.slice/session-3.scope
cgroup resource usage
The command can be used to see the resource usage:
$ systemd-cgtop
Control Group Tasks %CPU Memory Input/s Output/s user.slice 540 152,8 3.3G - - user.slice/user-1000.slice 540 152,8 3.3G - - user.slice/u…000.slice/session-1.scope 425 149,5 3.1G - - system.slice 37 - 215.6M - -
Custom cgroups
systemd unit files can be used to define a custom cgroup configuration. They must be placed in a systemd directory, such as . The resource control options that can be assigned are documented in .
This is an example slice unit that only allows 30% of one CPU to be used:
/etc/systemd/system/my.slice
CPUQuota=30%
Remember to run to pick up any new or changed files.
As service
Service unit file
Resources can be directly specified in service definition or as a
MemoryMax=1G # Limit service to 1 gigabyte
Grouping unit under a slice
Service can be specified what slice to run in:
Slice=my.slice
As root
can be used to run a command in a specific slice.
# systemd-run --slice=my.slice command
option can be used to spawn the command as specific user.
# systemd-run --uid=username --slice=my.slice command
The option can be used to spawn a command shell inside the slice.
As unprivileged user
Unprivileged users can divide the resources provided to them into new cgroups, if some conditions are met.
Cgroups v2 must be utilized for a non-root user to be allowed managing cgroup resources.
Controller types
Not all resources can be controlled by user.
| Controller | Can be controlled by user | Options |
|---|---|---|
| cpu | Requires delegation | CPUAccounting, CPUWeight, CPUQuota, AllowedCPUs, AllowedMemoryNodes |
| io | Requires delegation | IOWeight, IOReadBandwidthMax, IOWriteBandwidthMax, IODeviceLatencyTargetSec |
| memory | Yes | MemoryLow, MemoryHigh, MemoryMax, MemorySwapMax |
| pids | Yes | TasksMax |
| rdma | No | ? |
| eBPF | No | IPAddressDeny, DeviceAllow, DevicePolicy |
Note: eBPF is technically not a controller but those systemd options implemented using it and only root is allowed to set them.
User delegation
For user to control cpu and io resources, the resources need to be delegated. This can be done by creating a unit overload.
For example if your user id is 1000:
# systemctl edit [email protected]
Delegate=yes
Reboot and verify that the slice your user session is under has cpu and io controller:
$ cat /sys/fs/cgroup/user.slice/user-1000.slice/cgroup.controllers
cpuset cpu io memory pids
User-defined slices
The user slice files can be placed in .
To run the command under certain slice:
$ systemd-run --user --slice=my.slice command
You can also run your login shell inside the slice:
$ systemd-run --user --slice=my.slice --shell
Run-time adjustment
cgroups resources can be adjusted at run-time using command. Option syntax is the same as in .
Warning: The adjustments will be made permanent unless option is passed. Adjustments are saved at for system wide options and for user options.
Note: Not all resources changes immediately take effect. For example, changing TaskMax will only take effect on spawning new processes.
For example, cutting off internet access for all user sessions:
$ systemctl set-property user.slice IPAddressDeny=any
Типы systemd Unit файлов
Самый простой способ определить тип устройства — это посмотреть на его суффикс, который добавляется к концу имени ресурса (юнита). В следующем списке описаны типы unit-ов, доступных для systemd:
- .service: Данный юнит описывает, как управлять службой или приложением на сервере. Он в себе будет включать запуск или остановку службу, при каких обстоятельствах она должна автоматически запускаться, а также информацию о зависимости для соответствующего программного обеспечения.
- .socket: Файл сокет-устройства описывает сетевой, IPC-сокет или FIFO буфер, который systemd использует для активации сокета. Они всегда имеют связанный .service файл, который будет запущен при сокет активности, которая определяет этот блок.
- .device: Юнит, который описывает устройство, которое было указано как необходимое для управления systemd с помощью udev или файловой системы sysfs. Не все устройства имеют файлы .device. Некоторые скрипты, которым может потребоваться устройства .device, предназначены для монтирования и доступа к устройствам.
- .mount: Этот блок определяет точку монтирования в системе, которой управляет systemd. Они называются по пути монтирования, при этом «/» изменены на тире. Записи внутри /etc/fstab могут иметь блоки, созданные автоматически.
- .automount: Модуль .automount настраивает точку монтирования, которая будет автоматически установлена и должен быть определен после точки монтирования, на которую они ссылаются, и должны иметь соответствующий модуль .mount для определения особенностей монтирования.
- .swap: Данный юнит, описывает SWAP (пространство подкачки) в системе. Название этих блоков должно отражать путь к устройству или файлу.
- .target: Данный юнит используется для обеспечения точек синхронизации для других устройств при загрузке или изменения состояний. Они также могут использоваться для перевода системы в новое состояние.
- .path: Данный юнит, определяет путь, который может использоваться для активации на основе пути. По умолчанию, юнит будет запущен с тем же базовым именем. Это использует inotify для отслеживания изменения путей.
- .timer: Этот юнит, определяет таймер, который будет управляться systemd (аналог cron джоб) для задержки или запланированной активации. При достижении таймера будет запускаться соответствующий блок.
- .snapshot: Это юнит, создается автоматически командой snapshot systemctl. Он позволяет вам восстановить текущее состояние системы после внесения изменений. Снимки не сохраняются во время сеансов и используются для отката временных состояний.
- .slice: Он связан с узлами группы управления Linux, что позволяет ограничить ресурсы или назначить их для любых процессов, связанных с slice. Имя отражает его иерархическую позицию внутри дерева групп. Юниты размещаются в определенных slice по умолчанию в зависимости от их типа.
- .scope: Они создаются автоматически systemd из информации которую получили от его интерфейса шины. Они используются для управления наборами системных процессов, созданных извне.
Как вы можете видеть, существует множество различных юнитов с которыми взаимодействует система. Многие из них работают вместе, чтобы добавить функциональности. В основном, используется .service из-за их полезности.
Основные концепции
Поскольку CGroups используются для управления распределением ресурсов процессов, концепция CGroups должна включать как минимум две части: процесс и ресурсы:
- задача: задача, используемая для представления процесса.
- Подсистема: Подсистема, используемая для указания типа *** управления ресурсами ***, например: процессор, память и т. Д. В настоящее время Linux поддерживает 12 типов подсистем:
- blkio: ограничить скорость io для блочных устройств работы задач
- cpu: ограничить использование ЦП задачей
- cpuacct: неограниченный класс, генерировать отчет об использовании процессора задачи в cgroup
- cpuset: выделить независимый процессор и процессор для задач в cgroupУзел памяти
- устройства: устройства, к которым теперь могут обращаться задачи в контрольной группе
- freezer: задача в контрольной группе приостановлена, или приостановленная задача восстановлена до нормальной работы
- hugetlb: ограничить использование HugeTLB контрольной группы
- память: ограничить использование памяти задачей
- net_cls: отметьте сетевые пакеты, отправленные задачей,tcОбработаем отмеченные пакеты
- net_prio: установить приоритет сети для задачи
- perf_event: отслеживайте производительность cgroup, а не задачи
- pids: количество задач в живой контрольной группе (включая задачи в подчиненной контрольной группе)
Помимо процессов и ресурсов, также необходимо объединить их и предоставить эффективные методы управления:
- cgroup: управление группой, управление задачами в группах и установка количества выделяемых ресурсов по группам.
- иерархия: может пониматься как определенная или некоторые точки монтирования подсистемы, такие как:Справочник илиКаталог можно понимать как иерархию.
- Подсистема может появиться только в одной иерархии.Самый подробный случай состоит в том, что только одна подсистема монтируется в каждой иерархии.
- Подсистема, установленная в иерархии, определяет тип управления ресурсами, который может и может использоваться контрольной группой только в текущей иерархии, например:Cgroup *** может использовать только один тип памяти, и*** Используйте только комбинацию cpu и cpuacct. Это можно понимать так: все процессы в одной иерархии ограничивают ресурсы одними и теми же средствами, а разница заключается в пороге ресурсов между cgroup и cgroup.
- Каждая иерархия монтируется со всеми процессами в текущей системе. В исходном состоянии эти процессы принадлежат контрольной группе по умолчанию, которая называется корневой контрольной группой (Считайте, что каждая иерархия представляет собой полное дерево процессов), вы можете создавать подгруппы под корневой контрольной группой.
- Каждый процесс в иерархии может принадлежать только одной контрольной группе.Когда процесс добавляется в новую контрольную группу, система автоматически удаляет этот процесс из старой контрольной группы.
- Объединение всех подсистем в иерархию — это наиболее грубый метод управления процессами, поскольку каждый процесс использует все подсистемы одновременно.
- С каждой иерархией связана только одна подсистема. Это наиболее детализированный метод управления процессами. Каждый процесс в иерархии использует только одну подсистему.
На приведенном выше рисунке есть два дерева иерархии: иерархия-a и иерархия-b. Задачи (процессы) на двух деревьях абсолютно одинаковы, и подсистемы на двух деревьях не могут иметь пересечения. Методы группировки cgroup в дереве независимы друг от друга и не влияют друг на друга. Контрольная группа в иерархии-а должна использовать подсистемы cpu и cpuacct, в настоящее время cpu и cpuacct являются единым целым. И только один вид подсистемы памяти может использоваться в иерархии-b.
Когда процесс создает новый дочерний процесс, дочерний процесс и родительский процесс находятся в одной контрольной группе и подчиняются одним и тем же ограничениям подсистемы. После этого дочерний процесс может быть добавлен в другие контрольные группы, родительский процесс не затронут, а родительский и дочерний процессы независимы друг от друга.
Информация об оперативной памяти
1. Файл /proc/meminfo (Linux)
Команда:
cat /proc/meminfo
Пример ответа:
MemTotal: 8010284 kB
MemFree: 1058580 kB
MemAvailable: 2791616 kB
Buffers: 1884 kB
Cached: 1754092 kB
SwapCached: 122280 kB
Active: 4330296 kB
Inactive: 2006792 kB
Active(anon): 3623768 kB
Inactive(anon): 983120 kB
Active(file): 706528 kB
Inactive(file): 1023672 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 1048572 kB
SwapFree: 597684 kB
Dirty: 20 kB
Writeback: 0 kB
AnonPages: 4466532 kB
Mapped: 92808 kB
Shmem: 25776 kB
Slab: 408732 kB
SReclaimable: 308820 kB
SUnreclaim: 99912 kB
KernelStack: 7312 kB
PageTables: 23276 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 5053712 kB
Committed_AS: 3770324 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 159328 kB
VmallocChunk: 34359341052 kB
HardwareCorrupted: 0 kB
AnonHugePages: 3248128 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 257984 kB
DirectMap2M: 8130560 kB
* чаще всего, самое важное:
- MemTotal — общий объем оперативной памяти.
- MemFree — объем памяти, который не используется системой.
- Buffers — память, которая в данным момент ожидает записи на диск.
- Cached — объем, задействованный под кэш чтения с диска.
- MemAvailable — объем памяти, доступной в распределители без необходимости обмена.
- SwapTotal — объем файла подкачки.
- SwapFree — свободный объем файла подкачки.
* Объем используемой памяти = MemTotal – MemFree — Cached — Buffers.
Для перевода килобайт в гигабайты можно воспользоваться онлайн калькулятором.
2. free (Linux)
Данная команда позволяет получить информацию об использовании памяти в удобной таблице. Для еще большего удобства, мы выведем ее с помощью дополнительного параметра -h:
free -m
Пример ответа:
total used free shared buff/cache available
Mem: 3,7G 568M 378M 193M 2,8G 2,6G
Swap: 4,0G 94M 3,9G
sysctl hw.physmem
Пример ответа:
hw.physmem: 2123677696
4. dmesg
Работает на BSD и Linux:
dmesg | grep memory
Итог:
real memory = 2147483648 (2048 MB)
avail memory = 2042109952 (1947 MB)
5. Другие команды
Для получения информации по оперативной памяти также можно использовать команды:
vmstat -s
top
htop
* для htop необходима установка одноименной утилиты.
Спор вокруг систем инициализации в Linux
System V init (или просто «SysV») — это система инициализации, которая существует со времен операционной системы System V, которая была выпущена в 1983 году. SysV оставалась системой инициализации в течение почти трех десятилетий (за некоторыми исключениями). Многие IT-специалисты и программисты в силу своей привычки не хотели отказываться от SysV, да и к тому же она была очень простой для понимания.
Проблема с SysV заключалась в том, что в её основе лежали концепции, существовавшие много лет назад. SysV не хватало возможности нативно обрабатывать многие вещи, такие как: обнаружение съемных носителей, корректное обнаружение аппаратного обеспечения и загрузка встроенного ПО, загрузка различных модулей и пр. Кроме того, при использовании данной системы, инициализация процессов происходит последовательно, т.е. одна задача запускается только после успешного завершения предыдущей. Часто это приводило к задержке и длительному времени загрузки. Задачи, подобные монтированию файловых систем, выполняются один раз во время загрузки, после чего «забываются». Но такого подхода недостаточно для автоматизированного управления сервисами, требующими к себе постоянного внимания.
В попытке привнести больше возможностей в процесс инициализации Linux-систем, компания Canonical в 2006 году вместе с релизом Ubuntu 6.10 (Edgy Eft) выпускает систему инициализации Upstart, которая с самого начала разрабатывалась с учетом обратной совместимости. Она может запускать демоны без каких-либо изменений в их скриптах запуска.
Другой системой инициализации, восходящей своими корнями к операционной системе 4.4BSD, является rc.init. Она применяется в таких дистрибутивах, как: FreeBSD, NetBSD и Slackware. В 2007 году разработчики Gentoo выпустили улучшенный вариант данной системы инициализации, сделав её модульной и назвав OpenRC. Большинство других дистрибутивов Linux исторически продолжало использовать SysV.
В 2010 году инженеры компании Red Hat Леннарт Пёттеринг и Кей Сиверс приступили к разработке новой системы инициализации — systemd, которая разрабатывалась с учетом недостатков, имеющихся в SysV. В состав systemd, помимо прочего, также входят и различные пакеты, утилиты и библиотеки, позволяющие производить параллельный запуск процессов, сокращая тем самым время загрузки системы и количество необходимых вычислений. Весной того же года Fedora 15 стала первым дистрибутивом, в котором по умолчанию использовалась система инициализации systemd. После чего, на протяжении следующих трех лет, большинство дистрибутивов массово перешли на systemd.
Но, если все остальные дистрибутивы отдают предпочтение systemd и считают её лучшей системой инициализации, как для предприятий, так и для любителей, почему так много споров вокруг нее?
systemd, по сравнению с SysV и Upstart, содержит большое количество различных улучшений, а также предлагает и другие компоненты, имеющие более тесную интеграцию с системой, с помощью которых разработчики могут уменьшить объем выполняемой работы. Что в этом плохого? Ну, поскольку разработчики создают программное обеспечение, которое зависит от systemd и/или от любой из её многочисленных служб (journald, udevd, consoled, logind или networkd), то такое ПО становится менее совместимым с системами, в которых systemd не применяется. По мере того, как количество служб, предоставляемых проектом systemd, продолжает расти, systemd сама становится все более зависимой от них.
В результате systemd становится самостоятельной платформой, и её повсеместное распространение непреднамеренно препятствует разработке программного обеспечения, которое является переносимым и совместимым с операционными системами, не поддерживающими systemd. Но действительно ли всё так печально? Конечно, нет. Прежде всего, это проект с открытым исходным кодом, и у людей есть выбор: использовать его или нет. Пользователи и разработчики могут извлечь выгоду из наличия нескольких конкурирующих систем инициализации, и нет вины systemd в том, что основные дистрибутивы переключились на нее из-за её плюсов.
Общие понятия:
У каждого объекта в Linux есть свой идентификатор, а так же права доступа, применяемые к данному идентификатору. Идентификатор есть у пользователя — UID, у группы — GID, у файла — inod. Собственно inode является, как идентификатором файла/каталога, так и сущностью, которая содержит в себе информацию о файле/каталоге. Например такую, как: принадлежность к владельцу/группе, тип файла и права доступа к файлу.
Чтобы визуально лицезреть права доступа к файлу или каталогу, его тип и владельцев, а так же, если необходимо, и сам номер inode, необходимо выполнить следующую команду:
Print-server:/# ls -li итого 50 22089 drwxr-xr-x 2 root root 3072 Ноя 15 14:15 bin 32129 drwxr-xr-x 3 root root 1024 Окт 1 18:03 boot 12 lrwxrwxrwx 1 root root 11 Окт 1 15:36 cdrom -> media/cdrom 557 drwxr-xr-x 13 root root 3340 Ноя 17 06:25 dev 30121 drwxr-xr-x 50 root root 4096 Ноя 15 14:46 etc ....
Из вывода команды видно (рассмотрим первую строку):
22089
это есть номер inode
drwxr-xr-x
это есть те самые права доступа и тип файла (об этом ниже)
2
количество жестких ссылок на файл
root
имя владельца файла
root
имя группы владельца файла
3072
размер файла
Ноя 15 14:15
дата создания файла
bin
имя файла/каталога
Для каждого объекта файловой системы в модели полномочий Linux есть три типа полномочий: полномочия чтения (r от read), записи (w от write) и выполнения (x от execution). В полномочия записи входят также возможности удаления и изменения объекта. Право выполнения можно установить для любого файла. Потенциально, любой файл в системе можно запустить на выполнение, как программу в Windows. В Linux является ли файл исполняемым или нет, определяется не по его расширению, а по правам доступа. Кроме того, эти полномочия указываются отдельно для владельца файла, членов группы файла и для всех остальных.
Собрав вышесказанное в кучу, то есть представив 3 правила (rwx) для трех групп (владелец, группа, остальные) запись прав доступа будет выглядеть вот так: rwx rwx rwx(то есть владельцу разрешено чтение, выполнение и запись, группе разрешено то же самое и остальным). Рассмотрев права на папку /bin в выше приведенном листинге, можно представить такую картину:
drwxr-xr-x+ ||||||||||+наличие дополнительных прав (ACL) |||||||||+-исполнение для всех остальных - разрешено ||||||||+--запись для всех остальных - НЕ разрешено |||||||+---чтение для всех остальных - разрешено ||||||+----исполнение для группы владельца - разрешено |||||+-----запись для группы владельца - НЕ разрешено ||||+------чтение для группы владельца - разрешено |||+-------исполнение для владельца - разрешено ||+--------запись для владельца - разрешено |+---------чтение для владельца - разрешено +----------тип файла (об этом ниже...)
Кроме указанного представления полномочий доступа (символьного), существует так же и числовое представление. Для общего понимания, приведу таблицу соответствия числового (двоичного и десятичного) значения прав доступа и буквенного:
| владелец | группа | остальные | |
| буквенное | rwx | r-x | r— |
| числовое (десятичное) | 421 | 401 | 400 |
| итоговое | 7 | 5 | 4 |
В приведенной таблице показано, что право чтения, соответствует значению 4, право записи — 2, право выполнения — 1, отсутствие права — 0, складывая данные показатели, можно представлять и назначать права в числовом виде. Для примера, права rwx r-x r— будут соответствовать значению 754, потому что: rwx (4+2+1=7) r-x (4+0+1=5) r— (4+0+0=4). Так же, довольно распространена комбинация rw- (4+2+0=6). Думаю данный пример достаточно нагляден.
Информация о процессоре
Команды для получения данных о процессоре.
1. lscpu (Linux)
Команда показывает информацию о характеристиках процессора в удобном виде:
lscpu
Пример ответа:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 2
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 62
Model name: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
Stepping: 4
CPU MHz: 2592.918
BogoMIPS: 5187.50
Hypervisor vendor: VMware
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 20480K
NUMA node0 CPU(s): 0-7
* больше всего нас интересует:
- Architecture — архитектура процессора — 32 бит или 64.
- Core(s) per socket — количество ядер на процессор.
- Socket(s) — количество физических/виртуальных процессоров.
- CPU(s) — суммарное количество процессорных ядер.
- Model name — модель процессора.
2. sysctl -a (FreeBSD)
Команда отображает множество данных, поэтому добавляем фильтр:
sysctl -a | egrep -i ‘hw.machine|hw.model|hw.ncpu’
Пример ответа:
hw.model: Intel(R) Xeon(R) CPU X5690 @ 3.47GHz
hw.machine: amd64
hw.ncpu: 2
* на самом деле, команда sysctl работает и в Linux, но формат вывода менее удобен, по сравнению с вышерассмотренной lscpu.
3. Файл /proc/cpuinfo (Linux)
Позволяет увидеть подробную информацию по каждому ядру:
cat /proc/cpuinfo
Команда для подсчета количества ядер:
cat /proc/cpuinfo | grep processor | wc -l
Linux
Сначала необходимо установить утилиту.
На CentOS (RPM):
yum install lm_sensors
Ubuntu (Deb):
apt-get install lm-sensors
После установки утилиты выполняем:
sensors-detect
sensors
FreeBSD
Загружаем необходимый модуль:
kldload coretemp
* для автоматической его загрузки добавляем в файл /boot/loader.conf строку coretemp_load=»YES»
Вводим команду:
sysctl -a | grep temperature
Пример ответа:
dev.cpu.0.temperature: 40.0C
dev.cpu.1.temperature: 41.0C
Перемещение процессов между группами[править]
«Корень» созданной иерархии включает все процессы системы. Для того, чтобы установить ограничения только для конкретных процессов, следует создать для них отдельную группу в иерархии, подобно:
# mkdir -- /sys/fs/cgroup/rg42/lim1 #
Перенести выбранные процессы в эту группу можно просто записав их идентификаторы (pid) в файл созданной директории:
# printf %s\\n 4919 8192 > /sys/fs/cgroup/rg42/lim1/tasks #
«Возвращение» процессов в «корневую» группу (и, тем самым, — снятие ограничений) выполняется совершенно аналогично:
# printf %s\\n 8192 9320 > /sys/fs/cgroup/rg42/tasks #
Список групп, к которым отнесен данный процесс в настоящий момент (каждая иерархия позволяет отнести процесс к одной и только одной группе), можно найти в файле директории процесса:
$ cat < /proc/4919/cgroup 1:rg42:/lim1 $
