command:
cat /proc/sys/net/ipv4/ip_local_port_range
+
+{subsection: Partitions for the Job Queue}
+
+Carefully consider which partition is used for the job_queue.log file. This file is a transaction log for the HTCondor schedd; as such, it is frequently fsync'd to disk.
+
+This can be problematic if job outputs and the transaction log are on the same partition. The default ordering mode (data=ordered) on ext3 and ext4 cause all outstanding data to be flushed to disk during an fsync of the transaction log, which may include very large job outputs. This can cause significant latency for fsync to complete - slowing the schedd and making it unresponsive.
+
+Large submit hosts should consider one of the following options:
+*: Setting data=writeback in the partition's mount options.
+*: Moving the job_queue.log to a separate partition. Using a SSD is rarely needed.
+*: Using a different Linux filesystem, such as XFS.
+
+The first option requires the least changes to the host, but has some drawbacks. Applications which are not properly designed may lose data after a power loss as they rely on special ext3 behavior which is above and beyond POSIX. For ext4, there is also a possibility that delayed-allocation mode can cause garbage data to appear in files after a power cycle.
+
+{subsection: Max Connection Backlog}
+
+As of 8.1.5, HTCondor has a default connection backlog of 500; that means up to 500 clients may contact a daemon *while it is blocked* before they start getting connection errors. Many more than 500 clients may connect to the daemon total - this limit solely refers to the number of clients that connect before accept() is called on the TCP socket.
+
+Linux will silently truncate the maximum backlog to 128 connections unless a system-wide limit is raised. We recommend using:
+
+ echo 500 > /proc/sys/net/core/somaxconn
