Vraag Praktische maximaal geopende bestandsbeschrijvingen (ulimit -n) voor een systeem met een hoog volume


We zijn onlangs begonnen met het laden van onze applicatie en merkten op dat de bestandsdescriptors na ongeveer 24 uur op waren.

We gebruiken RHEL 5 op een Dell 1955:

CPU: 2 x dual core 2,66-GHz 4 MB 5150 / 1333FSB RAM: 8 GB RAM Harde schijf: 2 x 160 GB 2,5 "SATA harde schijven

Ik controleerde de bestandsdescriptor limiet en deze werd ingesteld op 1024. Gezien het feit dat onze applicatie mogelijk ongeveer 1000 inkomende verbindingen zou kunnen hebben evenals 1000 uitgaande verbindingen, lijkt dit vrij laag. Om nog maar te zwijgen van alle daadwerkelijke bestanden die moeten worden geopend.

Mijn eerste gedachte was om de ulimit -n-parameter met enkele orden van grootte te verhogen en vervolgens de test opnieuw uit te voeren, maar ik wilde weten wat de mogelijke consequenties zijn van het te hoog instellen van deze variabele.

Bestaan ​​er praktische tips om dit anders in te stellen dan uit te zoeken hoeveel bestandsdescriptors onze software theoretisch kan openen?


69
2017-07-31 22:35


oorsprong




antwoorden:


Deze limieten kwamen uit een tijd waarin meerdere "normale" gebruikers (niet apps) de server zouden delen en we manieren nodig hadden om hen te beschermen tegen het gebruik van te veel bronnen.

Ze zijn erg laag voor krachtige servers en we stellen ze meestal op een zeer hoog aantal. (24 k of zo) Als je hogere getallen nodig hebt, moet je ook de sysctl-bestand-max-optie wijzigen (over het algemeen beperkt tot 40k op ubuntu en 70k op rhel).

Ulimit instellen:

# ulimit -n 99999

Sysctl max-bestanden:

#sysctl -w fs.file-max=100000

Ook, en heel belangrijk, moet u mogelijk controleren of uw toepassing een geheugen / bestandsdescriptorlek heeft. Gebruik lsof om alles te zien dat geopend is om te zien of ze geldig zijn of niet. Probeer uw systeem niet te veranderen om bugs in toepassingen te omzeilen.


70
2017-08-01 13:08



@sucuri bedankt. We zijn absoluut bezorgd over bronlekken, maar dat lijkt niet het geval te zijn. We hebben zowel lsof als netstat in de gaten gehouden en terwijl de cijfers hoog zijn, blijven ze niet groeien, breiden ze uit en trekken ze samen. Ik verwacht dat als er een lek is, het aantal open bussen of descriptors in de loop van de tijd zal blijven groeien. - Kevin
De ulimit limiet is niet per gebruiker, maar per proces! Zien unix.stackexchange.com/questions/55319/...  En de fs.file-max instelling is voor de server als geheel (dus alle processen samen). - Tonin


Je zou altijd gewoon kunnen doen

cat /proc/sys/fs/file-nr

Tijdens de situatie 'hoge belasting' om te zien hoeveel bestandsdescriptoren in gebruik zijn.

Tot een maximum - het hangt er maar net van af wat je aan het doen bent.


13
2018-05-18 12:22



Hier was ik aan het denken dat 143000 goed genoeg was toen het bovenstaande commando me liet zien 8288 0 793377! - Sridhar-Sarnobat


Als de bestandsbeschrijvingen tcp-sockets zijn, enzovoort, riskeert u een grote hoeveelheid geheugen te gebruiken voor de socketbuffers en andere kernel-objecten; dit geheugen zal niet worden verwisseld.

Maar anders, nee, in principe zou er geen probleem moeten zijn. Raadpleeg de kerneldocumentatie om te proberen uit te zoeken hoeveel kernelgeheugen het zal gebruiken en / of test het.

We draaien database-servers met ~ 10k bestandsdescriptors open (meestal op echte schijfbestanden) zonder een groot probleem, maar ze zijn 64-bit en hebben heel veel ram.

De ulimit-instelling is per proces, maar er is ook een limiet voor het hele systeem (32k denk ik standaard)


6
2017-08-01 12:27





Ik ben niet persoonlijk op de hoogte van enige best practices. Het is enigszins subjectief, afhankelijk van de systeemfunctie.

Onthoud dat 1024 die u ziet een limiet per gebruiker is en geen limiet voor het hele systeem. Overweeg hoeveel toepassingen u op dit systeem uitvoert. Is dit de enige? Dient de gebruiker die deze applicatie draait iets anders te doen? (IE, hebben jullie mensen die dit account gebruiken om in te loggen en scripts uit te voeren die mogelijk weglopen?)

Aangezien het vak alleen deze ene applicatie draait en het account dat de applicatie draait alleen voor dat doel is, zie ik geen schade aan het verhogen van uw limiet zoals u suggereert. Als het een in-house dev-team is, zou ik om hun mening vragen. Als het afkomstig is van een externe leverancier, kunnen deze specifieke vereisten of aanbevelingen hebben.


2
2017-07-31 22:53



@Grahamux Het systeem is gewijd aan deze toepassing en de gebruiker die de toepassing uitvoert, voert deze toepassing alleen uit. Ik maak deel uit van het eigen Dev-team, dus geen hulp. - Kevin
De limiet is niet per gebruiker, maar per proces. Zien unix.stackexchange.com/questions/55319/... - Tonin


Dit lijkt mij een van die vragen die het best beantwoord kunnen worden met "test het in een ontwikkelomgeving". Ik herinner me jaren geleden dat Sun nerveus werd toen je hiermee knoeide, maar niet zo nerveus. Het is limiet op dat moment was ook 1024, dus ik ben een beetje verbaasd om te zien dat het nu hetzelfde is voor Linux, het lijkt erop dat het hoger zou moeten zijn.

Ik vond de volgende link educatief toen ik googlede voor antwoorden op je vraag: http://www.netadmintools.com/art295.html

En deze ook: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible


1
2017-08-01 00:51