Linux Books
@linuxkalii - наш канал По всем вопросам- @notxxx1 № 5032799382
Показати більше📈 Аналітичний огляд Telegram-каналу Linux Books
Канал Linux Books (@linux_read) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 16 023 підписників, посідаючи 8 106 місце в категорії Технології та додатки та 41 594 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 16 023 підписників.
За останніми даними від 07 липня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на -47, а за останні 24 години на -1, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 12.92%. Протягом перших 24 годин після публікації контент зазвичай збирає 4.57% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 2 071 переглядів. Протягом першої доби публікація в середньому набирає 733 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 16.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як linux, ядро, grep, скрипт, devops.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“@linuxkalii - наш канал
По всем вопросам- @notxxx1
№ 5032799382”
Завдяки високій частоті оновлень (останні дані отримано 08 липня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
Изоляция через tmpfs - мини-песочница без Docker
создаём каталог и подменяем его на чистый tmpfs
sudo mkdir -p /tmp/safezone
sudo mount -t tmpfs -o size=100M tmpfs /tmp/safezone
запускаем тестируемую команду в изоляции
cd /tmp/safezone
bash suspicious_script.sh
снимаем изоляцию
cd /
sudo umount /tmp/safezone
Изоляция через tmpfs - мини-песочница без Docker
создаём каталог и подменяем его на чистый tmpfs
sudo mkdir -p /tmp/safezone
sudo mount -t tmpfs -o size=100M tmpfs /tmp/safezone
запускаем тестируемую команду в изоляции
cd /tmp/safezone
bash suspicious_script.sh
снимаем изоляцию
cd /
sudo umount /tmp/safezoneps и top помогают получить общее представление, но цифры там часто обманчивы.
Процесс может выглядеть как прожорливый монстр, хотя значительная часть его памяти 0 shared, то есть разделяется с другими процессами. А наоборот, «лёгкий» процесс может скрытно потреблять больше через общие библиотеки и кэш.
Чтобы понять реальную картину, нужно копнуть глубже — в файловую систему /proc, а именно в файл smaps, где хранится подробная карта памяти каждого процесса.
Перед этим важно разобраться в трёх ключевых метриках:
- VSZ (Virtual Memory Size) — общий объём виртуальной памяти;
- RSS (Resident Set Size) — реальный объём памяти в RAM;
- PSS (Proportional Set Size) — точная оценка «реального» потребления с учётом разделяемых страниц.
💡 Эти метрики показывают, сколько памяти процесс действительно использует — и где она делится с другими.
Полный разбор и примеры смотри в оригинальном материале: blog.sysxplore.com/p/how-to-accurately-check-process-memory-usage-in-linuxtop или ps, но эти инструменты вводят в заблуждение. Они показывают RSS (Resident Set Size), который считает общую память как свою.
Например: если 5 процессов используют одну и ту же библиотеку на 100 МБ, RSS прибавит по 100 МБ к каждому, хотя в реальности эта память занимает только 100 МБ в RAM.
Чтобы понять реальный вклад процесса в потребление памяти, нужно смотреть PSS (Proportional Set Size) — метрику, которая делит общую память пропорционально между всеми пользователями.
📊 Три ключевые метрики:
- VSZ (Virtual Set Size) — общий виртуальный объём памяти, выделенный процессу.
→ Включает код, данные, библиотеки, маппинг файлов… но многое из этого может вообще не быть в RAM.
→ Не показывает реальное потребление RAM.
- RSS (Resident Set Size) — сколько памяти процесса фактически загружено в RAM сейчас.
→ Но считает общую память целиком, даже если она используется десятком других процессов.
→ Завышает реальное потребление.
- PSS (Proportional Set Size) — настоящий объём памяти, который освободится при завершении процесса.
→ Общая память делится поровну: если 3 процесса используют библиотеку на 90 МБ → каждый «платит» по 30 МБ.
→ Это самая точная метрика для оценки нагрузки на RAM.
🔧 Как получить PSS?
1. Найдите PID процесса:
pidof nginx
# или
ps aux | grep nginx
🔍 Как точно измерить, сколько памяти реально использует процесс в Linux
Когда система тормозит, первым делом смотрят top или ps — но эти инструменты вводят в заблуждение. Они показывают RSS (Resident Set Size), который считает общую память как свою.
Например: если 5 процессов используют одну и ту же библиотеку на 100 МБ, RSS прибавит по 100 МБ к каждому — хотя в реальности эта память занимает только 100 МБ в RAM.
Чтобы понять реальный вклад процесса в потребление памяти, нужно смотреть PSS (Proportional Set Size) - метрику, которая делит общую память пропорционально между всеми пользователями.
📊 Три ключевые метрики:
- VSZ (Virtual Set Size) — общий виртуальный объём памяти, выделенный процессу.
→ Включает код, данные, библиотеки, маппинг файлов… но многое из этого может вообще не быть в RAM.
→ Не показывает реальное потребление RAM.
- RSS (Resident Set Size) — сколько памяти процесса фактически загружено в RAM сейчас.
→ Но считает общую память целиком, даже если она используется десятком других процессов.
→ Завышает реальное потребление.
- PSS (Proportional Set Size) — настоящий объём памяти, который освободится при завершении процесса.
→ Общая память делится поровну: если 3 процесса используют библиотеку на 90 МБ → каждый «платит» по 30 МБ.
→ Это самая точная метрика для оценки нагрузки на RAM.
🔧 Как получить PSS?
1. Найдите PID процесса:
pidof nginx
# или
ps aux | grep nginx
2 Посчитайте суммарный PSS через /proc/[PID]/smaps:
sudo awk '/^Pss:/ { total += $2 } END { print total " kB" }' /proc/12345/smaps
Или, если у вас ядро Linux ≥ 4.15 — используйте готовую сводку:
sudo cat /proc/12345/smaps_rollup | grep Pss:
💡 Пример: процесс может показывать RSS = 800 МБ, но PSS = 120 МБ. Это значит, что только 120 МБ — его реальный вклад в использование RAM, остальное - общие библиотеки.
✅ Вывод
• Не доверяйте RSS из top или ps — он завышает потребление.
• Используйте PSS, чтобы понять, сколько памяти реально освободится, если убить процесс.
• Для точной диагностики всегда смотрите в /proc/[PID]/smaps или /proc/[PID]/smaps_rollup.
Источник: How to Accurately Check Memory Consumption of a Process in Linux# chown vasya /file
Назначить пользователя vasya владельцем файла file
# chown -R vasya directory
Рекурсивно обойти директорию directory и назначить пользователя vasya владельцем всех вложенных файлов и директорий
# chown vasya:group /file
Назначить владельца и группу для файла /file
# chmod ugo+rwx /directory
Установить полные права доступа rwx ( Read Write eXecute ) для всех ugo ( User Group Other ) на директорию /directory. То-же самое можно сделать, используя числовой представление chmod 777 directory
# chmod go-rwx /directory
Удалить все права на директорию /directory для группы и остальных
# chgrp new_group file
Изменить группу-владельца для file на new_group
# chmod o+t /home/public
Установить так называемый STIKY-бит на директорию /home/public. Удалить файл в такой директории может только владелец данного файла
# chmod o-t /home/public
Удалить STIKY-бит с директории /home/public
# chmod u+s /bin/binary_file
Установить SUID-бит на файл /bin/binary_file. Это позволяет любому пользователю системы, запускать данный файл с правами владельца файла
# chmod u-s /bin/binary_file
Удалить SUID-бит с файла /bin/binary_file
# chmod g+s /home/public
Установить SGID-бит на директории /home/public
# chmod g-s /home/public
Удалить SGID-бит с директории /home/public
# find / -perm -u+s
Поиск всех файлов с установленным SUID битом, начиная с корня файловой системы
# ls -lh
Листинг текущего каталога с правами доступаterraform apply в CI/CD - не лучший вариант. Важно видеть план изменений до деплоя, чтобы избежать неожиданных последствий.
В статье показано, как интегрировать Terraform с GitHub Actions так, чтобы каждый pull request автоматически запускал terraform plan. Результаты работы добавляются прямо в PR, где команда может просмотреть и обсудить изменения до их применения.
Таким образом:
- при открытии PR → генерируется план, прикрепляется к обсуждению;
- после ревью и мержа → автоматически выполняется terraform apply.
Это позволяет:
✅ повысить прозрачность изменений в инфраструктуре
✅ избежать ошибок при деплое
✅ упростить командную работу с IaC
Отличный пример того, как CI/CD можно использовать не только для приложений, но и для инфраструктуры.
https://itnext.io/github-actions-terraform-deployments-with-a-review-of-planned-changes-30143358bb5c
#devops #девопс