- RU.LINUX (2:5077/15.22) ------------------------------------------ RU.LINUX -
From : Peter V. Chernikoff 2:5020/1309.332 26 Apr 00 21:34:14
Subj : many open files per process (более 1024 открытых сокетов)
-------------------------------------------------------------------------------
Hi, Alexander !
On 25 Apr 2000 at 09:19, "AVR", Alexander V Rizov wrote:
>> Privet vsem! ne podskagete kak w linuxe mogno otkryt' bolee 1024
>> socketov na process
AVR> Hа процесс у меня не получилось, пробовал комбинации с fork-ом... В
AVR> результате при подходе где-то к 800-1000 (сейчас точно не помню) он
AVR> сказал, что слишком много открыто файлов в системе... Так что может
AVR> так просто и никак не сделаешь...
Привожу письмо из своих архивов, за содержание которого не несу
никакой ответственности.
Итак, повесть "Как я открыл в Linux 2000 файлов". Всем, кто любит 1C
посвящается. Привожу детальное описание действий по шагам. Hеобходимо:
1. Обнаружить что 1024 файлов на процесс для эксплуатации этого
угребища маловато.
2. Прочитать /usr/src/linux/Documentation/proc.txt возле волшебного
слова file-max. Обнаружить, что для изменения лимита per-process
надо изменить NR_OPEN в limits.h и fs.h находящихся в
/usr/src/include/linux.
3. Поменять их скажем на 2048.
4. сказать make zImage && make modules && make modules_install
5. прописать в lilo новое ядро, сказать lilo и перегрузиться.
6. обнаружить вопль get_unused_fd: тра-ля-ля и нежелание грузиться
7. Hажать Reset, загрузить старое ядро.
8. Вместо того, чтобы запускать newsreader и ныть в ru.linux что
звиздец эхотагу и флеймить о его пригодности для той или иной
задачи, зайти в /usr/src/linux/.
9. сказать rgrep get_unused_fd *.
10. Обнаружить эту функцию в fs/open.c
11. Обнаружить в ней следующий код:
=== struct files_struct * files = current->files;
int fd, error;
error = -EMFILE;
fd = find_first_zero_bit(&files->open_fds, NR_OPEN);
=== 12. Исследовать include/asm на предмет current и обнаружить что это
struct task_state
13. Исследовать include/linux/sched.h на предмет struct task_state и
увидеть что ее поле files представляет собой struct file_struct
14. Обнаружить, что поле open_fds в struct file_struct представляет
собой fd_set, что есть ни что иное, как __kernel_fd_set.
Последняя в свою очередь определена в include/linux/posix_types.h.
15. Обнаружить в include/linux/posix_types.h такой кусок кода:
===#undef __NFDBITS
#define __NFDBITS (8 * sizeof(unsigned long))
typedef struct {
unsigned long fds_bits [__FDSET_LONGS];
} __kernel_fd_set;
=== 16. Применив /dev/head сообразить, что стоило бы поставить
FD_SETSIZE >= NR_OPEN, например 2048.
17. Повторить шаги 4 и 5.
18. Сказать ulimit -n и увидеть 2048
19. Если еще не верится - скомпилить нижеприведенный суперпрограм:
===#include <stdio.h>
main ()
{
FILE *fp;
int i;
char name[100];
mkdir("testdir");
for(i = 0; i < 2000; i++) {
sprintf(name, "testdir/%d", i);
if ( (fp = fopen(name, "wb")) == NULL)
break;
}
printf("%d", i);
}
=== 20. Запустить ее и увидеть что в testdir - 2000 файлов.
Все это заняло у меня 40 минут, включая 2 компиляции ядра.
Примечания: 1) от шага 3 можно сразу перейти к шагу 16
2) передайте тем, кто заведует proc.txt и posix_types.h что не
помешало бы сделать __FD_SETSIZE зависимым от NR_OPEN или
хотябы это описать.
3) Внесите это в FAQ
4) В эксперименте принимали участие: ядро - 2.2.10, без ac-XXX ,
glibc-2.0.7-13, SysVinit-2.76-1. Дистрибутив - RH 5.1
Мораль сей басни такова: чем устраивать многодневный флейм по поводу
того нужны ли в MC часы и где им положено быть, проще взять исходники и
потратить полчаса максимум на добавление этих часов.
Это письмо написал грязный, волосатый, небритый му$@#к, в миру Kolya Nesterov
Press <Del> <Enter> [Team VT Dept]
==============================================================================--
Best regards -- /Peter
mailto: peter@digger.org.ru
--- Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Bryce Canyon)
* Origin: Juggernout News Server (2:5020/1309.332)
695 Прочтений • [many open files per process (более 1024 открытых сокетов) (proc file linux)] [08.05.2012] [Комментариев: 0]
Vova
