оптимізувати мій сервер Linux для обробки 10000 потоків за процес
Як пояснили інші, це взагалі неправильно. Нитка є дорогим ресурсом , в зокрема , тому , що він має свій власний стек викликів ( як правило, мегабайт) , а тому , що це планована завдання ядра. Нитки коштують навіть дорожче, ніж відкриті дескриптори файлів .
Прочитайте Операційні системи: Три простих фрагменти (підручник, що безкоштовно завантажується).
Як правило, ви не хочете мати багато ниток, і, звичайно, не багато запущених ниток. Кількість ниток, що можна виконати, як правило, повинна бути не більше кількості ядер (або малого кратного цього числа), тобто максимум близько десятка. Кількість потоків у процесі може бути трохи більшою. Тому, якщо у вас дуже розширюваний сервер (з багатьма процесорними розетками та ядрами), ви не хочете мати у своєму процесі більше десятка потоків, що можна виконувати, і сто потоків (більшість з яких простоюють) (на робочому столі) .
У Linux потоки та процеси дуже схожі (оскільки обидва можуть бути створені клоном (2) ), і обидва є завданнями, запланованими ядром. Насправді планувальник ядра планує завдання планування, які можуть бути потоками всередині якогось багатопотокового процесу, або єдиний головний потік однопотокового процесу (у такому випадку ви назвете "обробити" цей єдиний потік) або потоки ядра. Напевно, ви не хочете, щоб на вашому робочому столі було загалом більше тисячі завдань, які можна запланувати.
У Linux процес є просто групою потоків, що обмінюються тим самим віртуальним адресним простором (і спільним доступом до деяких інших речей, таких як таблиця дескрипторів файлів тощо). Деякі процеси мають лише одну нитку.
ВАП буде визначено Вікіпедією , як
"набір діапазонів віртуальних адрес, які операційна система робить доступними для процесу"
(але див. також цю відповідь, що пояснює, що термінологія не є універсальною, і в деяких документах Microsoft використовується інше і несумісне визначення).
В Linux, proc (5) корисно зрозуміти віртуальний адресний простір деяких процесів. Спробуйте
cat /proc/self/mapsі cat /proc/$$/mapsв терміналі. Дивіться також це , а також pmap (1) & ps (1) & top (1) .
Усі програми в просторі користувачів працюють у певному процесі та використовують віртуальну пам'ять, тому кожен процес має власний віртуальний адресний простір. Фізична ОЗУ - це ресурс, яким керує ядро Linux, а додатки не мають прямого доступу до оперативної пам’яті (за винятком mmap (2) -ing /dev/mem, див. Mem (4) ).
Тому процес не використовує безпосередньо оперативну пам'ять. Він використовує віртуальну пам'ять і має власний віртуальний адресний простір. Ядро використовує пейджинг для управління фізичної пам'яті сторінок і забезпечує віртуальний адресний простір і процес абстракції . У будь-який час (навіть коли ваш процес працює в режимі очікування або коли він працює) ядро може розгорнути деякі сторінки (наприклад, поміняти їх на диску). Ядро конфігурує MMU (і обробка сторінки пропускає апаратні винятки в деяких обробниках переривань , або шляхом отримання сторінки з диска, або шляхом поширення помилки сегментації в процесі, див. Сигнал (7) )
Ви можете мати зелені нитки над системними потоками (але бібліотеки зелених ниток важко реалізувати та налагоджувати). Подивіться на гороутини, які використовуються в Go для привабливого прикладу. Див. Також setcontext (3) .
Іноді ваша система може експериментувати з молотком . Це відбувається, коли загальна віртуальна пам'ять (необхідна всім процесам) перевищує - за великим фактором - наявну фізичну оперативну пам'ять. Тоді ваш комп’ютер стає безвідповідальним. Читайте про розмір набору резидентів , пейджинг попиту , робочий набір , перевиконання пам’яті , ASLR .
Дивіться також -для Linux- fork (2) , клон (2) , mmap (2) , madvise (2) , posix_fadvise (2) , mlock (2) , execve (2) , облікові дані (7) , pthreads (7) , futex (7) , можливості (7) .