Linux production notes
Non-Uniform Access Memory (NUMA) Hardware¶
For the majority of use cases, running q on a NUMA system can cause a number of operational issues, including high system-process usage and poor performance. Hence for these systems, you should disable NUMA and set an interleave memory policy. Q is unaware of whether NUMA is enabled or not.
If possible, disable NUMA in bios. Otherwise use the technique below.
To fully disable NUMA and set an interleave memory policy, start q with the
numactl command as follows
$ numactl --interleave=all q
$ echo 0 > /proc/sys/vm/zone_reclaim_mode
To find out whether NUMA is enabled in your bios, use
$ dmesg | grep -i numa
$ numactl -s
Huge Pages and Transparent Huge Pages (THP)¶
A number of customers have been impacted by bugs in the Linux kernel with respect to Transparent Huge Pages. These issues manifest themselves as process crashes, stalls at 100% CPU usage, and sporadic performance degradation. Until further notice, we strongly recommend disabling THP on Linux systems that run q.
Other database vendors are also reporting similar issues with THP.
Note that disabling Transparent Huge Pages isn’t possible via
sysctl(8). Rather, it requires manually echoing settings into /sys/kernel at or after boot. In /etc/rc.local or by hand:
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then echo never > /sys/kernel/mm/transparent_hugepage/enabled fi if test -f /sys/kernel/mm/transparent_hugepage/defrag; then echo never > /sys/kernel/mm/transparent_hugepage/defrag fi
$ echo never >/sys/kernel/mm/redhat_transparent_hugepage/enabled
Monitoring free disk space¶
In addition to monitoring free disk space for your usual partitions which you write to, ensure you also monitor free space of /tmp on Unix, since q uses this area for capturing the output from system commands, such as
If you find that q is seg faulting (crashing) when accessing compressed files, try increasing the Linux kernel parameter
vm.max_map_count. As root
$ sysctl vm.max_map_count=16777216
$ echo "vm.max_map_count = 16777216" | tee -a /etc/sysctl.conf $ sysctl -p
$ more /proc/sys/vm/max_map_count
max_map_countto 1 map per 128kB of memory, or 65530, whichever is higher.
If you are encountering a SIGBUS error, please check that the size of /dev/shm is large enough to accommodate the decompressed data. Typically, you should set the size of /dev/shm to be at least as large as a fully decompressed HDB partition.
Timekeeping on production servers is a complicated topic. These are just a few notes which can help.
If you are using any of local time functions
.z.(TPNZD) q will use the
localtime(3) system function to determine time offset from GMT. In some setups (GNU libc) this can cause excessive system calls to /etc/localtime.
Setting TZ environment helps this:
$ export TZ=America/New_York
.z.(pt…)is to have a slow clock source configured on your OS. Modern Linux distributions provide very low overhead functionality for getting current time. Use
tscclocksource to activate this.
$ echo tsc >/sys/devices/system/clocksource/clocksource0/current_clocksource # list available clocksource on the system $ cat /sys/devices/system/clocksource/clocksource*/available_clocksource