La limite par défaut pour les fichiers Open Max sur Mac OS X est 256 (ulimit -n) et mon application nécessite environ 400 gestionnaires de fichier.
J'ai essayé de modifier la limite avec SETRLIMIT () mais même si la fonction s'exécute Correctement, je suis toujours limité à 256.
Voici le programme de test que j'utilise: et la sortie est: < PRE> XXX Je ne peux pas demander aux personnes qui utilisent ma demande pour fouiller dans un fichier / etc. J'ai besoin de l'application pour le faire par lui-même.
6 Réponses :
Je sais que cela sonne une question idiote, mais vous avez vraiment besoin de 400 fichiers ouverts en même temps? Au fait, exécutez-vous ce code comme la racine êtes-vous?
Oui, j'ai besoin de 400 fichiers ouverts en même temps et non, je ne suis pas en tant que root. Comme le dit l'homme, puisque je ne change pas la limite maximale, mais juste la limite curlante, je n'ai pas besoin d'être root.
Mais ne pouvait pas limiter la limite de limite maximale?
rlp.rlim_cur = 10000;
Deux choses.
1er. MDR. Apparemment, vous avez trouvé un bogue dans le Mac OS X 'Stdio. Si je corrige votre programme / ajoutez la manipulation des erreurs / etc. et également remplacer fopen () avec Open () SysCall, je peux facilement atteindre la limite de 10000 (qui correspond à 240 FDS sous ma limite de 10,6,3 'Open_Max Limit 10240)
2e. RTFM:
homme setrlimit . Cas de fichiers Open Max doit être traité spécifiquement sur Open_max.
Thx pour la réponse. Êtes-vous sérieux lorsque vous dites que cela pourrait être un bug de Stdio sur Mac OS X ou une blague? Donc, la seule solution consiste à utiliser SysCall au lieu de la fonction C standard C?
@AcemTP: La limitation est probablement un mot meilleur. La norme ne nécessite que libc de garantir que vous pouvez ouvrir 8 fichiers à la fois (y compris stdin / stdout / starr !). Ce serait une limitation inhabituelle mais pas inouïe de.
@aceemp, @évan: Eh bien STDIO sur Linux n'a aucun problème à faire face à ce que je jette. Et je serais personnellement qualifié que comme un bogue. 8 fichiers à la fois ?? Stdio, Stdin, Stderne - 3 sont déjà occupés. Fichier de journal d'application + fichier de trace - Feuilles seulement 3 libres ... idiot et un bug, si vous me demandez.
Cela peut être une limite difficile de votre libc. Certaines versions de Solaris ont une limitation similaire car elles stockent le Aussi loin que je sache, des choses comme Bien sûr, vous ne pouvez toujours pas utiliser L'inconvénient est que vous devez utiliser Pouvez-vous décrire le scénario qui nécessite 400 fichiers ouverts ** simultanément **? Je ne dis pas qu'il n'y a pas de cas où cela est nécessaire. Mais si vous décrivez plus clairement votre cas d'utilisation, vous pouvez peut-être recommander une meilleure solution. fd en tant que sans signé Char dans le fichier struct. Si tel est aussi le cas pour votre libc, vous ne pourrez peut-être pas faire ce que vous voulez.
SETRLIMIT Effect Le nombre de fichiers que vous pouvez ouvrir avec Ouvrir (fopen est presque certainement implémenté en termes sur ouvert < / code>). Donc, si cette limitation est sur le niveau de libc, vous aurez besoin d'une solution alternative.
fopen et utiliser l'appel système Ouvrir disponible sur à peu près toutes les variantes d'UNIX.
écrire et lire au lieu de fwrite et fread , ce que Don 'T Faites des choses comme la mémoire tampon (c'est tout fait dans votre libc, pas par le système d'exploitation lui-même). Donc, cela pourrait finir par être un goulot d'étranglement de la performance.
Limite de libc: oui. Voir mon commentaire. Changer le programme pour utiliser Open () au lieu de Fopen () corrige le problème. Sur Linux BTW fonctionne comme un charme - après avoir apporté la solution évidente du remplacement du 10000 avec rlp.rlim_max (mais sur Mac OS X, même si le capuchon de Open_max doit également être vérifié). Scénario où vous avez besoin de 400 FDS ... Je maintiens le serveur de réseaux spécialisés qui recule également les données sur le disque. Voir des prises 2K 2K et ouvrir des fichiers utilisés n'est pas rare.
@ Dummy00001: OK, c'est certainement A Scénario, mais avoir ACEMTP Décrivez exactement ce qu'il tente de faire pourrait toujours aider :-p. Mais on dirait que nous avons trouvé la nature du problème.
etresoft a trouvé la réponse sur le Panneau de discussion Apple :
Tout le problème ici est votre Fonction Printf (). Quand vous appelez printf (), vous initialisez structures de données internes à un certain Taille. Ensuite, vous appelez SETRLIMIT () à Essayez d'ajuster ces tailles. Ce fonction échoue parce que vous avez déjà utilisé ces internes structures avec votre printf (). Si vous utiliser deux structures rlimit (un pour avant et un pour après), et ne pas Imprimez-les jusqu'à ce que après avoir appelé setrlimit, vous constaterez que vous pouvez changer les limites du courant processus même dans une ligne de commande programme. La valeur maximale est 10240.
Pour une raison quelconque (peut-être la compatibilité binaire), vous devez définir Imprimés P> _darwin_unlimited_streams code> avant y compris before 256 -1
after 10000 -1
failed after 9997
Mac OS ne nous permet pas de modifier facilement la limite comme dans la plupart du système d'exploitation basé sur UNIX. Nous devons créer deux fichiers
/library/launchdaemons/limit.maxfiles.plist /Library/launchdaemons/limit.maxproc.plist décrivant la limite de fichier maximale Proc et Max. La propriété du fichier doit être modifiée en «racine: roue»
Ceci seul ne résout pas le problème, par défaut la dernière version de Mac OSX utilise 'CSRUTIL', nous devons le désactiver. Pour le désactiver, nous devons redémarrer notre Mac en mode de récupération et à partir de là désactivez CSUTTIL à l'aide de la borne.
Maintenant, nous pouvons facilement modifier la limite maximale de la poignée de fichier ouverte maximale de la borne elle-même (même en mode de démarrage normal).
Cette méthode est expliquée en détail dans le lien suivant. http://blog.dekstroza.io/ulimit-shénanigans-on -osx-el-capitan /
fonctionne pour OSX-elcapitan et OSX-Seirra.
OP demandait comment procéder à cela par programme, en C, pas au niveau de l'utilisateur.
Pourquoi avez-vous besoin de tant de fichiers ouverts simultanément?
Non pas que cela devrait être important, mais testez-vous cela sur l'édition de serveur ou l'édition de bureau d'OSX? Je peux imaginer que les pommes des Apple ont décidé de limiter le nombre de fichiers qu'une application de bureau pouvait ouvrir une application de bureau puisqu'il d'ouvrir de nombreuses tâches est généralement une tâche orientée du serveur ...