"быстрый дистрибутив"

Вопросы программного кода и архитектуры Linux

Модератор: Olej

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

"быстрый дистрибутив"

Непрочитанное сообщение Olej » 23 июл 2012, 12:46

Не раз встречал подобный "оборот речи" :lol:
Последний раз нашёл на форуме Linux в Сургуте, в теме относительно ArchLinux:
4) очень быстрый дистрибутив, сравнимый по скорости с Gentoo;
То же самое и здесь в разделе форума звучало не раз, а в других местах на обсуждениях - так просто массово (причём у каждого обсуждающего именно его дистрибутив "быстрый" :lol: ).

Во-первых, откуда такое мнение, в частности и о Gentoo? (ссылочку может кто знает ... или просто мнение имеет).

Но, во-вторых, ещё интереснее:

1. может ли вообще дистрибутив быть "быстрее" или "медленнее"?
(когда разговор идёт о таких дистрибутивах как List of Linux distributions that run from RAM то это совсем другая песня к делу не относящаяся, там всё понятно)

2. "быстрый" это как? быстрый при загрузке? (тогда вам в Fedora с его systemd ;-) )

3. или быстрый в GUI окружении? а в каком именно из них?

4. или быстрый в консольных командах? каким образом?

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

Или это всё-таки просто такой красивый "оборот речи"? :lol: :
- Люблю отдельные красивые слова!

(с) Сатин, Максим Горький, "На дне".

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: "быстрый дистрибутив"

Непрочитанное сообщение Olej » 06 сен 2012, 01:00

Olej писал(а): 1. может ли вообще дистрибутив быть "быстрее" или "медленнее"?
Очень много в оценке "отзывчивости" дистрибутива (что субъективно воспринимается как скорость) определяется настройками системы.

Самая известная (обсуждаемая) из таких настроек это то, что связано с использованием раздела/файла/разделов подкачки, и эффективности их использования.

Конспективно:

1. посмотреть:

Код: Выделить всё

bash-4.2$ swapon -s
Filename				Type		Size	Used	Priority
/dev/sda2                               partition	3071996	187684	0
2. отформатировать раздел подкачки и подключить:

Код: Выделить всё

# mkswap /dev/hdd1
# swapon /dev/hdd1
3. создать, отформатировать файл подкачки и подключить

Код: Выделить всё

# dd if=/dev/zero of=/swapfile bs=1024 count=1048576
# mkswap /swapfile
# swapon /swapfile
(1048576 - это размер файла в килобайтах, т.е. 1Гб)

5. загрузить swap в RAM и прекратить свопирование:

Код: Выделить всё

# swapoff -a 
6. загрузить swap в RAM (освежить):

Код: Выделить всё

# swapoff -a && sudo swapon -a
(отключить + включить)

7. чтобы не делать swapoff/swapon раздел/файл swap подключают постоянно, через /etc/fstab, конечно, что-то типа:

Код: Выделить всё

/swapfile none swap sw 0 0
8. разделов/файлов swap может быть не 1, а сколько угодно, причём им может приписываться приоритет использования; наивысший приоритет выглядит так:

Код: Выделить всё

# swapon -p 1 /swapfile
Приоритет является целым числом от 0 до 32767.

9. Эффективность использования подкачки - http://rus-linux.net/lib.php?name=MyLDP ... /swap.html:
Ядро Linux 2.6 добавило новый параметр, называемый swappiness (перевода не существует), позволяющий администратору регулировать то, как Линукс оперирует с пространством подкачки. Это число от 0 до 100. В общих чертах, чем больше это число, тем больше страниц откачиваются из оперативной памяти на диск, а чем меньше значение swappiness, тем большее число приложений остаются в оперативной памяти, даже если они неактивны. Разработчик ядра Andrew Morton утверждает, что выставляет на своих десктопах swappiness на высочайший уровень - 100, говоря при этом: "Я считаю, что не следует ограничивать ядро в его стремлении откачивать мусор. Вы же не хотите, чтобы сотни мегабайт памяти, занятой раздувшимися приложениями, без пользы зависли в вашей машине. Выгрузите их на диск, а память используйте на что-нибудь полезное". У идеи Мортона есть и оборотная сторона: если память освобождается слишком быстро, то время отклика приложений возрастет, так как при вызове приложения, система должна будет сначала закачать его обратно в память, что создаст ощущение медлительности.
Значение swappiness по умолчанию равно 60.

Код: Выделить всё

bash-4.2$ cat /proc/sys/vm/swappiness
60
Можно изменить его временно (до следующей перезагрузки) командой от имени root:

Код: Выделить всё

# echo 50 > /proc/sys/vm/swappiness
Или так:

Код: Выделить всё

# sysctl vm.swappiness=50
10. Постоянное (после перезагрузки ОС) изменение swappiness:
- в файле /etc/sysctl.conf ...
- найти строку vm.swappiness=60 и изменить значение...
- если данной строки не будет, значит нужно дописать ее в конце файла:

Код: Выделить всё

vm.swappiness=50
11. На многих современных аппаратных конфигурациях стоит столько RAM (2Gb, 4Gb, 8Gb), что использовать подкачку становится рудиментом дурного тона - это привычки былых времён. Или нет?
P.S. Это сказано только для рабочих станций, с серверами там совсем другая история, и там использование подкачки совершенно уместно.

Уже с этими только настройками можно подстроить систему как "быструю" под тот класс работ, которыми вы занимаетесь.

Но это далеко не всё.
Предлагаю поделиться у кого есть какие соображения по оптимизации.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: "быстрый дистрибутив"

Непрочитанное сообщение Olej » 06 сен 2012, 01:10

Olej писал(а): 2. "быстрый" это как? быстрый при загрузке? (тогда вам в Fedora с его systemd ;-) )
Некоторые субъективные наблюдения:

1. при последовательных обновлениях от Fedora 12 до Fedora 14 (это ещё без systemd) время загрузки увеличивалось последовательно до 2 раз (субъективно) ... но это может сильно зависеть от числа запускаемых сервисов.

2. Fedora 17 (systemd) на том же ноутбуке загружается ... ну, раз до 2-х (или чуть поменее), надо отдать должное, быстрее чем Fedora 12 ... секунд 50-70.

3. Но вот с SSD диском Ubuntu 10.04, на более слабом процессоре (Atom, на тех же 1.6Ghz), загружается от тумблера питания до графического login - 8 сек., а выключает питание - 6 сек.

Так что будущее скорости в смысле загрузки-выключения (что бывает важным для систем высокой готовности) не в выборе "хитрых" дистрибутивов, и не в способах параллельной загрузки (systemd), а в использовании системных SSD (на сегодня стоимость 64Gb SSD не превышает стоимости среднего HDD).

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: "быстрый дистрибутив"

Непрочитанное сообщение Olej » 06 сен 2012, 01:32

Olej писал(а):Предлагаю поделиться у кого есть какие соображения по оптимизации.
Можно поиграться (увеличить/уменьшить) объёмом потребляемой системой RAM за счёт изменения размеров дискового кеша. Уровень выделяемой под кеш памяти хранится в:

Код: Выделить всё

bash-4.2$ cat /proc/sys/vm/vfs_cache_pressure 
100
Это обычно значение по умолчанию.

Уменьшить (что вообще говоря не есть хорошая идея):

Код: Выделить всё

# echo 50 > /proc/sys/vm/vfs_cache_pressure 
Увеличить (хочется больше отзывчивости системы):

Код: Выделить всё

# echo 1000 > /proc/sys/vm/vfs_cache_pressure 
Для того, чтобы понравившиеся нам настройки стали постоянными, опять же заносим параметр

Код: Выделить всё

vm.vfs_cache_pressure = 1000
- в файл /etc/sysctl.conf (редактируем или добавляем строку).

Что там у нас получилось с распределением использования RAM смотрим:

Код: Выделить всё

bash-4.2$ free
             total       used       free     shared    buffers     cached
Mem:       2057664    1834360     223304          0      33624     411240
-/+ buffers/cache:    1389496     668168
Swap:      3071996     209152    2862844

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: "быстрый дистрибутив"

Непрочитанное сообщение Olej » 08 сен 2012, 12:20

Olej писал(а):
Olej писал(а): 1. может ли вообще дистрибутив быть "быстрее" или "медленнее"?
Очень много в оценке "отзывчивости" дистрибутива (что субъективно воспринимается как скорость) определяется настройками системы.
Но и настройки это далеко не всё ... чтобы ощущать дистрибутив быстрым или медленным.
В Linux есть такая совершенно дикая фича, как "диспетчирование в ядре по дисциплинам real-time" ... вообще то, у меня такое впечатление, что это рудимент мании величия команды разработчиков ядра из тех времён, когда они ещё не понимали, что такое real-time, и что это "такое" - недостижимо в Linux.

Но как-бы там ни было, для процесса (правильнее: для главного и любого потока процесса) могут быть установлены несколько дисциплин диспетчеризации (/usr/include/bits/sched.h):

Код: Выделить всё

/* Scheduling algorithms.  */
#define SCHED_OTHER             0
#define SCHED_FIFO              1
#define SCHED_RR                2
#ifdef __USE_GNU
# define SCHED_BATCH            3
# define SCHED_IDLE             5
Вот те 2 последних мне никак не удалось получить ... возможно, из оставили из услужливости к GNU? или требует перекомпиляции (ядра? системных библиотек GCC?).
Это 1-й попутный вопрос: как? ;-)

Но вот с остальными очень интересно.
Практически все процессы в вашем Linux управляются SCHED_OTHER. Это предмет особой гордости команды ядра - алгоритм диспетчирования степени роста O(const) - время не зависит от числа N диспетчируемых процессов. При этом каждый процесс получает квант выполнения, который в зависимости от приоритета и интерактивности может принять значения 5-800 системных тиков (обычно тик это 1 мс.). И при этом любой самый низкоприоритетный процесс когда-то всё-таки получит минимум своего процессорного времени.

Но есть ещё real-time диспетчирование: SCHED_FIFO и SCHED_RR. И здесь до тех пор, пока такой поток активный, ни один другой процесс/поток SCHED_OTHER не получит ни кванта процессорного времени.
Достаточно удивительно, что в Linux существует несколько таких потоков (FF):

Код: Выделить всё

bash-4.2$ ps -Ao pid,ppid,policy,rtprio,nice,pri,comm | grep -v TS
  PID  PPID POL RTPRIO  NI PRI COMMAND
    6     2 FF      99   - 139 migration/0
    7     2 FF      99   - 139 watchdog/0
    8     2 FF      99   - 139 migration/1
   11     2 FF      99   - 139 watchdog/1
(можно заметить, что всё это потоки ядра).

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: "быстрый дистрибутив"

Непрочитанное сообщение Olej » 08 сен 2012, 13:30

Olej писал(а): Но есть ещё real-time диспетчирование: SCHED_FIFO и SCHED_RR. И здесь до тех пор, пока такой поток активный, ни один другой процесс/поток SCHED_OTHER не получит ни кванта процессорного времени.
Так вот такие процессы иногда могут работать в вашей системе, и это субъективно будет восприниматься как "туповатость" системы.
И реально такие потоки могут присутствовать в разных публичных проектах, ... насколько помнится, именно так работают некоторые протокольные модули (PRI & SS7?) VoIP серверов (Asterisk, FreeSWITCH).

А возможность запуска процессов (потоков) с SCHED_FIFO и SCHED_RR иногда очень полезная... но это больше в системах ближе к промышленному применению. Я сделал небольшой проект, демонстрирующий запуск любого приложения Linux с SCHED_FIFO и SCHED_RR, с тем, чтобы можно было понаблюдать как это будет сказываться на отзывчивости системы (которую и путают с "быстрая").

Любопытные могут поиграться! ;-)

Код: Выделить всё

bash-4.2$ sudo ./rte  -t5 -v -pRR
20:58:802 : pid=11541   : main started
20:58:802 : pid=11542   : child loop started
20:58:803 : pid=11541   : set scheduling RR with priority=99
21:03:803 : pid=11541   : send signal 3 to child
21:03:803 : pid=11542   : received signal 3 from parent
21:03:803 : pid=11541   : main finished

bash-4.2$ ps -Ao pid,ppid,policy,rtprio,nice,pri,comm | ( head -n1 && grep rte )
  PID  PPID POL RTPRIO  NI PRI COMMAND
11541 11540 TS       -   0  19 rte
11542 11541 RR      99   - 139 rte
- вот так запускается внутренняя копия fork-процесса, который просто тупо циклится. Опции -t5 - прекратить это безобразие через 5 сек. после запуска, -v - отладочный вывод, -p - дисциплина диспетчеризации дочернего процесса (FIFO, RR, OTHER).

Код: Выделить всё

bash-4.2$ ./rte  -t5 -v -pRR
21:57:243 : pid=11555   : main started
21:57:244 : pid=11556   : child loop started
sched_setscheduler: Operation not permitted
21:57:244 : pid=11555   : set scheduling OTHER with priority=0
22:02:244 : pid=11555   : send signal 3 to child
22:02:244 : pid=11556   : received signal 3 from parent
22:02:244 : pid=11555   : main finished

bash-4.2$ ps -Ao pid,ppid,policy,rtprio,nice,pri,comm | ( head -n1 && grep rte )
  PID  PPID POL RTPRIO  NI PRI COMMAND
11555  3214 TS       -   0  19 rte
11556 11555 TS       -   0  19 rte
- вот что происходит, если FIFO & RR устанавливать без прав root (Operation not permitted).

Код: Выделить всё

bash-4.2$ sudo ./rte  -t5 -v -pRR ls
20:12:606 : pid=11525   : main started
20:12:606 : pid=11526   : execute command: ls
20:12:606 : pid=11525   : set scheduling RR with priority=99
common.c  common.h  Makefile  rte  rte.0.c  rte.1.c  rte.c  rtech  rtech.c
20:17:606 : pid=11525   : main finished
bash-4.2$ sudo ./rte  -t5 -v -pRR 'ls -l ./'
24:52:644 : pid=4358	: main started
24:52:644 : pid=4359	: execute command: ls -l ./ 
24:52:645 : pid=4358	: set scheduling RR with priority=99
итого 44
-rw-r--r--. 1 olej olej  519 сент.  8 11:36 common.c
-rw-r--r--. 1 olej olej  276 сент.  8 11:40 common.h
-rw-r--r--. 1 olej olej  284 сент.  8 11:52 Makefile
-rwxrwxr-x. 1 olej olej 9421 сент.  8 13:24 rte
-rw-r--r--. 1 olej olej 3502 сент.  8 11:49 rte.c
-rwxrwxr-x. 1 olej olej 6471 сент.  8 13:24 rtech
-rw-r--r--. 1 olej olej  560 сент.  8 02:18 rtech.c
-rw-rw-r--. 1 olej olej 2896 сент.  8 13:16 rte.hist
24:57:645 : pid=4358	: main finished
- вот так запускается любая программа, но с диспетчированием FIFO & RR (если у программы должны быть опции, то чтобы не путать их с опциями rte, нужно команду запуска обрамлять кавычками: ' или ").

Код: Выделить всё

bash-4.2$ sudo ./rte  -t5 -v -pFIFO './rtech -v'
19:15:278 : pid=11510   : main started
19:15:278 : pid=11511   : execute command: ./rtech -v
19:15:279 : pid=11511   : programm in progress: ./rtech -v
19:15:279 : pid=11510   : set scheduling FIFO with priority=99
19:20:279 : pid=11510   : send signal 3 to child
19:20:282 : pid=11510   : main finished

bash-4.2$ ps -Ao pid,ppid,policy,rtprio,nice,pri,comm | ( head -n1 && grep rte )
  PID  PPID POL RTPRIO  NI PRI COMMAND
11510 11509 TS       -   0  19 rte
11511 11510 FF      99   - 139 rtech
- вот так rte запускает (а через 5 сек. прерывает) собственную тестовую задачу rtech.
Вложения
rt.tgz
(2.67 КБ) 454 скачивания

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: "быстрый дистрибутив"

Непрочитанное сообщение Olej » 09 сен 2012, 11:42

Olej писал(а): А возможность запуска процессов (потоков) с SCHED_FIFO и SCHED_RR иногда очень полезная... но это больше в системах ближе к промышленному применению. Я сделал небольшой проект, демонстрирующий запуск любого приложения Linux с SCHED_FIFO и SCHED_RR, с тем, чтобы можно было понаблюдать как это будет сказываться на отзывчивости системы (которую и путают с "быстрая").
Для тех, кто любит экспериментировать с программным кодом:

- я попутно доделал этот проектик в части, не относящейся к предмету обсуждения (пользуясь случаем - о другом ;-) )...

- теперь в одном из вариантов (программа rtet, а не rte) любое изменение планирования (дисциплина планирования, приоритеты, ...) сделано не относительно процесса (вызовы sched_setscheduler(), sched_getscheduler(), sched_getparam()), а применительно только к потокам (вызовы pthread_setschedparam(), pthread_getschedparam() ), но применительно неявно к главному потоку процесса, который и представляет процесс.

Чем это интересно?
Да тем, что:
- вопреки распространённому стереотипу (заблуждению?) в операционной системе процессы не являются исполнимой, динамической единицей, они не диспетчеризуются и не выполняются - это только статическая оболочка, обрамляющая ресурсы, принадлежащие всем потокам процесса...
- а динамической единицей (выполняемой, диспетчеризуемой, к которой относятся такие понятия как приоритет) является поток, даже если этот поток явно нигде и не фигурирует, является главным потоком процесса, и маскируется ;-) под процесс.

P.S. это особенно отчётливо видно при наблюдении потоков ядра, и в OS Solaris, где потоки ядра впервые и появились (из ОС широкого применения), ... а потом перекочевали и в Linux.
Вложения
rt.tgz
(10.55 КБ) 484 скачивания

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: "быстрый дистрибутив"

Непрочитанное сообщение Olej » 09 сен 2012, 15:03

Olej писал(а): Но есть ещё real-time диспетчирование: SCHED_FIFO и SCHED_RR. И здесь до тех пор, пока такой поток активный, ни один другой процесс/поток SCHED_OTHER не получит ни кванта процессорного времени.
Интересно вот что:

- в ОС действительно обеспечивающих требования real-time - QNX 6.x - и строго следующих требованиям расширения real-time POSIX 1003.b (которые и описывают такие стратегии планирования как SCHED_FIFO, SCHED_RR, SCHED_SPORADIC, SCHED_ADAPTIVE и т.п.), простейшая программа xxx типа:

Код: Выделить всё

while( 1 ) {};
- запущенная с одним из этих SCHED_* и повышенным относительно среднего (дефаултного) приоритетом:

Код: Выделить всё

# nice -n-19 xxx
- должна "забивать" терминал (или консоль) и его клавиатуру, т.е. делать систему непригодной: диспетчирование реального времени не оставляет ни одного кванта задачам более низкого приоритета!
- в Linux этого не происходит...
- что может значить только то, что всё real-time диспетчирование у них идёт только на уровне имитации, в рамках их общего O(1) планирования (с двумя массивами чередующихся очередей заданий: текущий-active и истекший-expired ), а не отдельным механизмом real-time планирования ... о котором пишут Р.Лав и другие (возможно, это так и было ... но несколько ранее ;-) ).

P.S. Хотя ... возможно наблюдаемый эффект происходит оттого, что все тестовые прогоны сейчас (по нынешним временам, на современных процессорах) удаётся выполнять только на многопроцессорных архитектурах (2, 4 ядра) и, из за достаточно жёсткой привязки процесса к процессору, на 100% загружается только один процессор?
Это нужно будет обязательно проверить!

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: "быстрый дистрибутив"

Непрочитанное сообщение Olej » 09 сен 2012, 15:33

Olej писал(а):P.S. Хотя ... возможно наблюдаемый эффект происходит оттого, что все тестовые прогоны сейчас (по нынешним временам, на современных процессорах) удаётся выполнять только на многопроцессорных архитектурах (2, 4 ядра) и, из за достаточно жёсткой привязки процесса к процессору, на 100% загружается только один процессор?
Это нужно будет обязательно проверить!
Вот в таком смысле ;-) :

Код: Выделить всё

bash-4.2$ sudo ./rte -t30 -v -pFIFO
25:24:629 : pid=5523	: main started
25:24:631 : pid=5524	: child loop started
25:26:453 : pid=5523	: set scheduling FIFO with priority=99
25:56:453 : pid=5523	: send signal 3 to child
25:56:453 : pid=5524	: received signal 3 from parent
25:56:454 : pid=5523	: main finished
Вложения
монитор_016.png
монитор_016.png (74.75 КБ) 8898 просмотров

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: "быстрый дистрибутив"

Непрочитанное сообщение Olej » 09 сен 2012, 15:42

Olej писал(а): - в Linux этого не происходит...
- что может значить только то, что всё real-time диспетчирование у них идёт только на уровне имитации, в рамках их общего O(1) планирования (с двумя массивами чередующихся очередей заданий: текущий-active и истекший-expired ), а не отдельным механизмом real-time планирования ... о котором пишут Р.Лав и другие (возможно, это так и было ... но несколько ранее ;-) ).

P.S. Хотя ... возможно наблюдаемый эффект происходит оттого, что все тестовые прогоны сейчас (по нынешним временам, на современных процессорах) удаётся выполнять только на многопроцессорных архитектурах (2, 4 ядра) и, из за достаточно жёсткой привязки процесса к процессору, на 100% загружается только один процессор?
Это нужно будет обязательно проверить!
Число процессоров:

Код: Выделить всё

bash-4.2$ cat /proc/cpuinfo | grep processor | wc -l
2
Запускаю 2 экземпляра (с 2-х терминалов) задачи (по отладочным меткам времени хорошо видно, что времена их выполнения перекрываются):

Код: Выделить всё

bash-4.2$ sudo ./rte -t30 -v -pFIFO
25:11:912 : pid=5520    : main started
25:11:913 : pid=5521    : child loop started
25:11:916 : pid=5520    : set scheduling FIFO with priority=99
25:42:453 : pid=5520    : send signal 3 to child
25:42:502 : pid=5521    : received signal 3 from parent
25:42:502 : pid=5520    : main finished

bash-4.2$ sudo ./rte -t30 -v -pFIFO
25:24:629 : pid=5523    : main started
25:24:631 : pid=5524    : child loop started
25:26:453 : pid=5523    : set scheduling FIFO with priority=99
25:56:453 : pid=5523    : send signal 3 to child
25:56:453 : pid=5524    : received signal 3 from parent
25:56:454 : pid=5523    : main finished
монитор_019.png
монитор_019.png (72.41 КБ) 8899 просмотров
Эффект состоит в том, что:
- мышка практически умирает...
- переключить рабочий стол, или вкладку терминала (посмотреть со стороны) невозможно.

Так что я в своём предположении о real-time планировании в Linux - неправ.

P.S. Но "практически" - это ещё не значит "абсолютно": мышь почти умирает, она непригодна для использования ... но её можно немного продвигать, а значит загрузка не 2*100%, и "обычным" приложениям остаётся какой-то квант ... чего при real-time планировании быть не должно.

P.P.S. Что интересно: почему на картинке системного монитора такое короткое перекрытие периодов загрузки 2-х процессоров? ... когда по меткам времени (в терминале) перекрытие порядка 14 сек., т.е. 50% периода 100% загрузки...
А это потому, что из-за такой загрузки CPU программа системного монитора практически приостановлена, и не "продвигает" свою шкалу. ;-). Т.е. на картинке в вот той (почти отсутствующей) области перекрытия "сокрылось" около 14 сек. шкалы. ;-)

Ответить

Вернуться в «Linux изнутри»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 7 гостей