1<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" 2 "http://www.w3.org/TR/html4/loose.dtd"> 3 4<html> 5 6<head> 7 8<title>Postfix Performance Tuning</title> 9 10<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 11<link rel='stylesheet' type='text/css' href='postfix-doc.css'> 12 13</head> 14 15<body> 16 17<h1><img src="postfix-logo.jpg" width="203" height="98" alt=""> 18Postfix Performance Tuning</h1> 19 20<hr> 21 22<h2>Purpose of Postfix performance tuning </h2> 23 24<p> The hints and tips in this document help you improve the 25performance of Postfix systems that already work. If your Postfix 26system is unable to receive or deliver mail, then you need to solve 27those problems first, using the DEBUG_README document as guidance. 28 29<p> For tuning external content filter performance, first read the 30respective information in the FILTER_README and SMTPD_PROXY_README 31documents. Then make sure to avoid latency in the content filter 32code. As much as possible avoid performing queries against external 33data sources with a high or highly variable delay. Your content 34filter will run with a small concurrency to avoid CPU/memory 35starvation, and if any latency creeps in, content filter throughput 36will suffer. High volume environments should avoid RBL lookups, 37complex database queries and so on. </p> 38 39<p>Topics on mail receiving performance: </p> 40 41<ul> 42 43<li> <a href="#server_tips">General mail receiving performance tips</a> 44 45<li> <a href="#speedup">Doing more work with your SMTP server processes</a> 46 47<li> <a href="#slowdown">Slowing down SMTP clients that make many errors</a> 48 49<li> <a href="#conn_limit">Measures against clients that make too many connections</a> 50 51</ul> 52 53<p>Topics on mail delivery performance: </p> 54 55<ul> 56 57<li> <a href="#mailing_tips">General mail delivery performance tips</a> 58 59<li> <a href="#hammer">Tuning the frequency of deferred mail delivery attempts</a> 60 61<li> <a href="#rope">Tuning the number of simultaneous deliveries</a> 62 63<li> <a href="#rcpts">Tuning the number of recipients per delivery</a> 64 65</ul> 66 67<p>Other Postfix performance tuning topics: </p> 68 69<ul> 70 71<li> <a href="#proc_limit">Tuning the number of Postfix processes</a> 72 73<li> <a href="#proc_sys">Tuning the number of processes on the system</a> 74 75<li> <a href="#file_limit">Tuning the number of open files or 76sockets</a> 77 78</ul> 79 80<p> The following tools can be used to measure mail system performance 81under artificial loads. They are normally not installed with Postfix. 82</p> 83 84<ul> 85 86<li> <a href="smtp-source.1.html">smtp-source, SMTP/LMTP message 87generator</a> 88 89<li> <a href="smtp-sink.1.html">smtp-sink, SMTP/LMTP message dump 90</a> 91 92<li> <a href="qmqp-source.1.html">qmqp-source, QMQP message generator 93</a> 94 95<li> <a href="qmqp-sink.1.html">qmqp-sink, QMQP message dump </a> 96 97</ul> 98 99<h2><a name="server_tips">General mail receiving performance 100tips</a></h2> 101 102<ul> 103 104<li> <p> Read and understand the maildrop queue, incoming queue, 105and active queue discussions in the QSHAPE_README document. </p> 106 107<li> <p> Run a local name server to reduce slow-down due to DNS 108lookups. If you run multiple Postfix systems, point each local name 109server to a shared forwarding server to reduce the number of lookups 110across the upstream network link. </p> 111 112<li> <p> Eliminate unnecessary LDAP lookups, by specifying a domain 113filter. This eliminates lookups for addresses in remote domains, 114and eliminates lookups of partial addresses. See ldap_table(5) for 115details. </p> 116 117</ul> 118 119<p> When Postfix responds slowly to SMTP clients: </p> 120 121<ul> 122 123<li> <p> <a href="DEBUG_README.html#logging">Look for obvious signs 124of trouble</a> as described in the DEBUG_README document, and 125eliminate those problems first. </p> 126 127<li> <p> Turn off your header_checks and body_checks patterns and 128see if the problem goes away. </p> 129 130<li> <p> <a href="DEBUG_README.html#no_chroot">Turn off chroot 131operation</a> as described in the DEBUG_README document and see 132if the problem goes away. </p> 133 134<li> <p> If Postfix logs the SMTP client as "unknown" then you have 135a name service problem: the name server is bad, or the resolv.conf 136file contains bad information, or some packet filter is blocking 137the DNS requests or replies. </p> 138 139<li> <p> If the number of smtpd(8) processes has reached the process 140limit as specified in master.cf, new SMTP clients must wait until 141a process becomes available. See the STRESS_README and POSTSCREEN_README 142documents for measures that help to prevent SMTP server overload. </p> 143 144</ul> 145 146<h2><a name="speedup">Doing more work with your SMTP server 147processes</a></h2> 148 149<p> With Postfix versions 2.0 and earlier, the smtpd(8) server 150pauses before reporting an error to an SMTP client. The idea is 151called tar pitting. However, these delays also slow down Postfix. 152When the smtpd(8) server replies slowly, sessions take more time, 153so that more smtpd(8) server processes are needed to handle the 154load. When your Postfix smtpd(8) server process limit is reached, 155new clients must wait until a server process becomes available. 156This means that all clients experience poor performance. </p> 157 158<p> You can speed up the handling of smtpd(8) server error replies 159by turning off the delay: </p> 160 161<blockquote> 162<pre> 163/etc/postfix/main.cf: 164 # Not needed with Postfix 2.1 165 smtpd_error_sleep_time = 0 166</pre> 167</blockquote> 168 169<p> With the above setting, Postfix 2.0 and earlier can serve more 170SMTP clients with the same number SMTP server processes. The next 171section describes how Postfix deals with clients that make a large 172number of errors. </p> 173 174<h2><a name="slowdown"> Slowing down SMTP clients that make many errors</a></h2> 175 176<p> The Postfix smtpd(8) server maintains a per-session error count. 177The error count is reset when a message is transferred successfully, 178and is incremented when a client request is unrecognized or 179unimplemented, when a client request violates <a 180href="SMTPD_ACCESS_README.html">access restrictions</a>, or when 181some other error happens. </p> 182 183<p> As the per-session error count increases, the smtpd(8) server 184changes behavior and begins to insert delays into the responses. 185The idea is to slow down a run-away client in order to limit resource 186usage. The behavior is Postfix version dependent. </p> 187 188<p> IMPORTANT: These delays slow down Postfix, too. When too much 189delay is configured, the number of simultaneous SMTP sessions will 190increase until it reaches the smtpd(8) server process limit, and new 191SMTP clients must wait until an smtpd(8) server process becomes available. 192</p> 193 194<p> Postfix version 2.1 and later:</p> 195 196<ul> 197 198<li> <p> When the error count reaches $smtpd_soft_error_limit 199(default: 10), the Postfix smtpd(8) server delays all non-error and 200error responses by $smtpd_error_sleep_time seconds (default: 1 201second). </p> 202 203<li><p>When the error count reaches $smtpd_hard_error_limit 204(default: 20) the Postfix smtpd(8) server breaks the connection. </p> 205 206</ul> 207 208<p> Postfix version 2.0 and earlier:</p> 209 210<ul> 211 212<li> <p> When the error count is less than $smtpd_soft_error_limit 213(default: 10) the Postfix smtpd(8) server delays all error replies by 214$smtpd_error_sleep_time (1 second with Postfix 2.0, 5 seconds with 215Postfix 1.1 and earlier). </p> 216 217<li> <p> When the error count reaches $smtpd_soft_error_limit, 218the Postfix smtpd(8) server delays all responses by "error count" 219seconds or $smtpd_error_sleep_time, whichever is more. </p> 220 221<li><p>When the error count reaches $smtpd_hard_error_limit 222(default: 20) the Postfix smtpd(8) server breaks the connection. </p> 223 224</ul> 225 226<h2><a name="conn_limit">Measures against clients that make too many connections</a></h2> 227 228<p> Note: these features use the Postfix anvil(8) service, introduced 229with Postfix version 2.2. </p> 230 231<p> The Postfix smtpd(8) server can limit the number of simultaneous 232connections from the same SMTP client, as well as the connection 233rate and the rate of certain SMTP commands from the same client. 234These statistics are maintained by the anvil(8) server (translation: 235if anvil(8) breaks, then connection limits stop working). </p> 236 237<p> IMPORTANT: These limits must not be used to regulate legitimate 238traffic: mail will suffer grotesque delays if you do so. The limits 239are designed to protect the smtpd(8) server against abuse by 240out-of-control clients. </p> 241 242<blockquote> 243 244<dl> 245 246<dt> smtpd_client_connection_count_limit (default: 50) </dt> <dd> 247The maximum number of connections that an SMTP client may make 248simultaneously. </dd> 249 250<dt> smtpd_client_connection_rate_limit (default: no limit) </dt> 251<dd> The maximum number of connections that an SMTP client may make 252in the time interval specified with anvil_rate_time_unit (default: 25360s). </dd> 254 255<dt> smtpd_client_message_rate_limit (default: no limit) </dt> <dd> 256The maximum number of message delivery requests that an SMTP client 257may make in the time interval specified with anvil_rate_time_unit 258(default: 60s). </dd> 259 260<dt> smtpd_client_recipient_rate_limit (default: no limit) </dt> 261<dd> The maximum number of recipient addresses that an SMTP client 262may specify in the time interval specified with anvil_rate_time_unit 263(default: 60s). </dd> 264 265<dt> smtpd_client_new_tls_session_rate_limit (default: no limit) 266</dt> <dd> The maximum number of new TLS sessions (without using 267the TLS session cache) that an SMTP client may negotiate in the 268time interval specified with anvil_rate_time_unit (default: 60s). 269</dd> 270 271<dt> smtpd_client_auth_rate_limit (default: no limit) </dt> <dd> 272The maximum number of AUTH commands that an SMTP client may send 273in the time interval specified with anvil_rate_time_unit (default: 27460s). Available in Postfix 3.1 and later. </dd> 275 276<dt> smtpd_client_event_limit_exceptions (default: $mynetworks) 277</dt> <dd> SMTP clients that are excluded from connection and rate 278limits specified above. </dd> 279 280</dl> 281 282</blockquote> 283 284<h2><a name="mailing_tips">General mail delivery performance tips</a></h2> 285 286<ul> 287 288<li> <p> Read and understand the maildrop queue, incoming queue, 289active queue and deferred queue discussions in the QSHAPE_README 290document. </p> 291 292<li> <p> In case of slow delivery, run the qshape tool as described 293in the QSHAPE_README document. </p> 294 295<li> <p> Submit multiple recipients per message instead of submitting 296messages with only a few recipients. </p> 297 298<li> <p> Submit mail via SMTP instead of /usr/sbin/sendmail. You 299may have to adjust the smtpd_recipient_limit parameter setting. 300</p> 301 302<li> <p> Don't overwhelm the disk with mail submissions. Optimize 303the mail submission rate by tuning the number of parallel submissions 304and/or by tuning the Postfix in_flow_delay parameter setting. </p> 305 306<li> <p> Run a local name server to reduce slow-down due to DNS 307lookups. If you run multiple Postfix systems, point each local name 308server to a shared forwarding server to reduce the number of lookups 309across the upstream network link. </p> 310 311<li> <p> Reduce the smtp_connect_timeout and smtp_helo_timeout 312values so that Postfix does not waste lots of time connecting 313to non-responding remote SMTP servers. </p> 314 315<li> <p> Use a dedicated mail delivery transport for problematic 316destinations, with reduced timeouts and with adjusted concurrency. 317See "<a href="#rope">Tuning the number of simultaneous deliveries</a>" 318below. 319</p> 320 321<li> <p> Use a fallback_relay host for mail that cannot be delivered 322upon the first attempt. This "graveyard" machine can use shorter 323retry times for difficult to reach destinations. See "<a 324href="#hammer">Tuning the frequency of deferred mail delivery 325attempts</a>" below. </p> 326 327<li> <p> Speed up disk updates with a large (64MB) persistent write 328cache. This allows disk updates to be sorted for optimal access 329speed without compromising file system integrity when the system 330crashes. </p> 331 332<li> <p> Use a solid-state disk (a persistent RAM disk). This 333is an expensive solution that should be used in combination 334with short SMTP timeouts and a fallback_relay "graveyard" 335machine that delivers mail for problem destinations. </p> 336 337</ul> 338 339<h2><a name="rope">Tuning the number of simultaneous deliveries</a></h2> 340 341<p> Although Postfix can be configured to run 1000 SMTP client 342processes at the same time, it is rarely desirable that it makes 3431000 simultaneous connections to the same remote system. For this 344reason, Postfix has safety mechanisms in place to avoid this 345so-called "thundering herd" problem. </p> 346 347<p> The Postfix queue manager implements the analog of the TCP slow 348start flow control strategy: when delivering to a site, send a 349small number of messages first, then increase the concurrency as 350long as all goes well; reduce concurrency in the face of congestion. 351</p> 352 353<ul> 354 355<li> <p> The initial_destination_concurrency parameter (default: 5) 356controls how many messages are initially sent to the same destination 357before adapting delivery concurrency. Of course, this setting is 358effective only as long as it does not exceed the process limit and 359the destination concurrency limit for the specific mail transport 360channel. </p> 361 362<li> <p> The default_destination_concurrency_limit parameter (default: 36320) controls how many messages may be sent to the same destination 364simultaneously. You can override this setting for specific message 365delivery transports by taking the name of the master.cf entry 366and appending "_destination_concurrency_limit". </p> 367 368</ul> 369 370<p> Examples of transport specific concurrency limits are: </p> 371 372<ul> 373 374<li> <p> The local_destination_concurrency_limit parameter (default: 3752) controls how many messages are delivered simultaneously to the 376same local recipient. The recommended limit is low because delivery 377to the same mailbox must happen sequentially, so massive parallelism 378is not useful. Another good reason to limit delivery concurrency 379to the same recipient: if the recipient has an expensive shell 380command in her .forward file, or if the recipient is a mailing list 381manager, you don't want to run too many instances of those processes 382at the same time. </p> 383 384<li> <p> The default smtp_destination_concurrency_limit of 20 seems 385enough to noticeably load a system without bringing it to its knees. 386Be careful when changing this to a much larger number. </p> 387 388</ul> 389 390<p> The above default values of the concurrency limits work well 391in a broad range of situations. Knee-jerk changes to these parameters 392in the face of congestion can actually make problems worse. 393Specifically, large destination concurrencies should never be the 394default. They should be used only for transports that deliver mail 395to a small number of high volume domains. </p> 396 397<p> A common situation where high concurrency is called for is on 398gateways relaying a high volume of mail between the Internet 399and an intranet mail environment. Approximately half the mail 400(assuming equal volumes inbound and outbound) will be destined 401for the internal mail hubs. Since the internal mail hubs will be 402receiving all external mail exclusively from the gateway, it is 403reasonable to configure the gateway to make greater demands on the 404capacity of the internal SMTP servers. </p> 405 406<p> The tuning of the inbound concurrency limits need not be trial 407and error. A high volume capable mailhub should be able to easily 408handle 50 or 100 (rather than the default 20) simultaneous connections, 409especially if the gateway forwards to multiple MX hosts. When all 410MX hosts are up and accepting connections in a timely fashion, 411throughput will be high. If any MX host is down and completely 412unresponsive, the average connection latency rises to at least 1/N 413* $smtp_connect_timeout, if there are N MX hosts. This limits 414throughput to at most the destination concurrency * N / 415$smtp_connect_timeout. </p> 416 417<p> For example, with a destination concurrency of 100 and 2 MX 418hosts, each host will handle up to 50 simultaneous connections. If 419one MX host is down and the default SMTP connection timeout is 30s, 420the throughput limit is 100 * 2 / 30 ~= 6 messages per second. This 421suggests that high volume destinations with good connectivity and 422multiple MX hosts need a lower connection timeout, values as low 423as 5s or even 1s can be used to prevent congestion when one or 424more, but not all MX hosts are down. </p> 425 426<p> If necessary, set a higher <i>transport</i>_destination_concurrency_limit 427(in main.cf since this is a queue manager parameter) and a lower 428smtp_connect_timeout (with a "-o" override in master.cf since 429this parameter has no per-transport name) for the relay transport 430and any transports dedicated for specific high volume destinations. 431</p> 432 433<h2><a name="rcpts">Tuning the number of recipients per delivery</a></h2> 434 435<p> The default_destination_recipient_limit parameter (default: 43650) controls how many recipients a Postfix delivery agent will send 437with each copy of an email message. You can override this setting 438for specific Postfix delivery agents. For example, 439"uucp_destination_recipient_limit = 100" would limit the number of 440recipients per UUCP delivery to 100. </p> 441 442<p> If an email message exceeds the recipient limit for some 443destination, the Postfix queue manager breaks up the list of 444recipients into smaller lists. Postfix will attempt to send multiple 445copies of the message in parallel. </p> 446 447<p> IMPORTANT: Be careful when increasing the recipient limit per 448message delivery; some SMTP servers abort the connection when they 449run out of memory or when a hard recipient limit is reached, so 450that the message will never be delivered. </p> 451 452<p> The smtpd_recipient_limit parameter (default: 1000) controls 453how many recipients the Postfix smtpd(8) server will take per 454delivery. The default limit is more than any reasonable SMTP client 455would send. The limit exists to protect the local mail system 456against a run-away client. </p> 457 458<h2><a name="hammer">Tuning the frequency of deferred mail delivery attempts</a></h2> 459 460<p> When a Postfix delivery agent (smtp(8), local(8), etc.) is 461unable to deliver a message it may blame the message itself, or it 462may blame the receiving party. </p> 463 464<ul> 465 466<li> <p> When the delivery agent blames the message, the queue 467manager gives the queue file a time stamp into the future, so it 468won't be looked at for a while. By default, the amount of time to 469cool down is the amount of time that has passed since the message 470arrived. This results in so-called exponential backoff behavior. 471</p> 472 473<li> <p> When the delivery agent blames the receiving party (for 474example a local recipient user, or a remote host), the queue manager 475not only advances the queue file time stamp, but also puts the 476receiving party on a "dead" list so that it will be skipped for 477some amount of time. </p> 478 479</ul> 480 481<p> This process is governed by a bunch of little parameters. </p> 482 483<blockquote> 484 485<dl> 486 487<dt> queue_run_delay (default: 300 seconds; before Postfix 2.4: 4881000s) </dt> <dd> How often 489the queue manager scans the queue for deferred mail. </dd> 490 491<dt> minimal_backoff_time (default: 300 seconds; before Postfix 4922.4: 1000s) </dt> <dd> The 493minimal amount of time a message won't be looked at, and the minimal 494amount of time to stay away from a "dead" destination. </dd> 495 496<dt> maximal_backoff_time (default: 4000 seconds) </dt> <dd> The 497maximal amount of time a message won't be looked at after a delivery 498failure. </dd> 499 500<dt> maximal_queue_lifetime (default: 5 days) </dt> <dd> How long 501a message stays in the queue before it is sent back as undeliverable. 502Specify 0 for mail that should be returned immediately after the 503first unsuccessful delivery attempt. </dd> 504 505<dt> bounce_queue_lifetime (default: 5 days, available with Postfix 506version 2.1 and later) </dt> <dd> How long a MAILER-DAEMON message 507stays in the queue before it is considered undeliverable. Specify 5080 for mail that should be tried only once. </dd> 509 510<dt> qmgr_message_recipient_limit (default: 20000) </dt> <dd> The 511size of many in-memory queue manager data structures. Among others, 512this parameter limits the size of the short-term, in-memory list 513of "dead" destinations. Destinations that don't fit the list are 514not added. </dd> 515 516<dt> <i>transport</i>_destination_concurrency_failed_cohort_limit 517</dt> <dd> Controls when a destination is considered "dead". This 518parameter is critical with a non-zero 519<i>transport</i>_destination_rate_delay, with a reduced 520<i>transport</i>_destination_concurrency_limit, or with 521a reduced initial_destination_concurrency. </dd> 522 523</dl> 524 525</blockquote> 526 527<p> IMPORTANT: If you increase the frequency of deferred mail 528delivery attempts, or if you flush the deferred mail queue frequently, 529then you may find that Postfix mail delivery performance actually 530becomes worse. The symptoms are as follows: </p> 531 532<ul> 533 534<li> <p> The active queue becomes saturated with mail that has 535delivery problems. New mail enters the active queue only when 536an old message is deferred. This is a slow process that usually 537requires timing out one or more SMTP connections. </p> 538 539<li> <p> All available Postfix delivery agents become occupied 540trying to connect to unreachable sites etc. New mail has to wait 541until a delivery agent becomes available. This is a slow process 542that usually requires timing out one or more SMTP connections. </p> 543 544</ul> 545 546<p> When mail is being deferred frequently, fixing the problem is 547always better than increasing the frequency of delivery attempts. 548However, if you can control only the delivery attempt frequency, 549consider using a dedicated fallback_relay "graveyard" machine for 550bad destinations, so that these destinations do not ruin the 551performance of normal 552mail deliveries. </p> 553 554<h2><a name="proc_limit">Tuning the number of Postfix processes</a></h2> 555 556<p> The default_process_limit configuration parameter gives direct 557control over how many daemon processes Postfix will run. As of 558Postfix 2.0 the default limit is 100 SMTP client processes, 100 559SMTP server processes, and so on. This may overwhelm systems with 560little memory, as well as networks with low bandwidth. </p> 561 562<p> You can change the global process limit by specifying a 563non-default default_process_limit in the main.cf file. For example, 564to run up to 10 SMTP client processes, 10 SMTP server processes, 565and so on: </p> 566 567<blockquote> 568<pre> 569/etc/postfix/main.cf: 570 default_process_limit = 10 571</pre> 572</blockquote> 573 574<p> You need to execute "postfix reload" to make the change effective. 575This limit is enforced by the Postfix master(8) daemon which does 576not automatically read main.cf when it changes. </p> 577 578<p> You can override the process limit for specific Postfix daemons 579by editing the master.cf file. For example, if you do not wish to 580receive 100 SMTP messages at the same time, but do not want to 581change the process limits for other Postfix daemons, you could 582specify: </p> 583 584<blockquote> 585<pre> 586/etc/postfix/master.cf: 587 # ==================================================================== 588 # service type private unpriv chroot wakeup maxproc command + args 589 # (yes) (yes) (yes) (never) (100) 590 # ==================================================================== 591 . . . 592 smtp inet n - - - 10 smtpd 593 . . . 594</pre> 595</blockquote> 596 597<h2><a name="proc_sys">Tuning the number of processes on the system</a></h2> 598 599<ul> 600 601<li> <p> MacOS X will run out of process slots when you increase 602Postfix process limits. The following works with OSX 10.4 and OSX 60310.5. </p> 604 605<p> MacOS X kernel parameters can be specified in /etc/sysctl.conf. 606</p> 607 608<pre> 609/etc/sysctl.conf: 610 kern.maxproc=2048 611 kern.maxprocperuid=2048 612</pre> 613 614<p> Unfortunately these can't simply be set on the fly with "sysctl 615-w". You also have to set the following in /etc/launchd.conf so 616that the root user after boot will have the right process limit 617(2048). Otherwise you have to always run ulimit -u 2048 as root, 618then start a user shell, and then start processes for things to 619take effect. </p> 620 621<pre> 622/etc/launchd.conf: 623 limit maxproc 2048 624</pre> 625 626<p> Once these are in place, reboot the system. After that, the limits will 627stay in place. </p> 628 629</ul> 630 631<h2><a name="file_limit">Tuning the number of open files or sockets</a></h2> 632 633<p> When Postfix opens too many files or sockets, processes will 634abort with fatal errors, and the system may log "file table full" 635errors. </p> 636 637<ul> 638 639<li> <p> Depending on your Postfix and operating system versions 640you may need to recompile Postfix if you need more than 1024 file 641descriptors per process: </p> 642 643<ul> <li> <p> No recompilation is needed for Postfix version 2.4 644and later, when it was compiled for systems that support BSD kqueue(2) 645(FreeBSD 4.1, NetBSD 2.0, OpenBSD 2.9), Solaris 8 /dev/poll, or 646Linux 2.6 epoll(4). </p> 647 648<li> <p> Otherwise, Postfix needs to be recompiled to override the 649default FD_SETSIZE value. </p> 650 651</ul> 652 653<li> <p> Reduce the number of processes as described under "<a 654href="#proc_limit">Tuning the number of Postfix processes</a>" above. 655Fewer processes need fewer open files and sockets. </p> 656 657<li> <p> Configure the kernel for more open files and sockets. 658The details are extremely system dependent and change with the 659operating system version. Be sure to verify the following information 660with your system tuning guide: </p> 661 662<ul> 663 664<li> <p> Some FreeBSD kernel parameters can be specified in 665/boot/loader.conf, and some can be specified in /etc/sysctl.conf 666or changed with sysctl commands. 667Which is which depends on the version. 668</p> 669 670<pre> 671kern.ipc.maxsockets="5000" 672kern.ipc.nmbclusters="65536" 673kern.maxproc="2048" 674kern.maxfiles="16384" 675kern.maxfilesperproc="16384" 676</pre> 677 678<li> <p> Linux kernel parameters can be specified in /etc/sysctl.conf 679or changed with sysctl commands: </p> 680 681<pre> 682fs.file-max=16384 683kernel.threads-max=2048 684</pre> 685 686<li> <p> Solaris kernel parameters can be specified in /etc/system, 687as described in the <a 688href="http://www.science.uva.nl/pub/solaris/solaris2.html#q3.48">Solaris 689FAQ</a> entry titled "How can I increase the number of file 690descriptors per process?" </p> 691 692<pre> 693* set hard limit on file descriptors 694set rlim_fd_max = 4096 695* set soft limit on file descriptors 696set rlim_fd_cur = 1024 697</pre> 698 699</ul> 700 701</ul> 702 703</body> 704 705</html> 706