MUUG meeting, March 2018

Contents

RTFM: ulimit(1)/limit(1)

• Built-in shell commands; ulimit is in shells descended from the Bourne shell, limit is from csh and tcsh

  core file size          (blocks, -c) 0
  data seg size           (kbytes, -d) unlimited
  scheduling priority             (-e) 0
  file size               (blocks, -f) unlimited
  pending signals                 (-i) 46372
  max locked memory       (kbytes, -l) 64
  max memory size         (kbytes, -m) unlimited
  open files                      (-n) 1024
  pipe size            (512 bytes, -p) 8
  POSIX message queues     (bytes, -q) 819200
  real-time priority              (-r) 0
  stack size              (kbytes, -s) 8192
  cpu time               (seconds, -t) unlimited
  max user processes              (-u) 46372
  virtual memory          (kbytes, -v) unlimited
  file locks                      (-x) unlimited
  

• Setting affects current shell and its child processes

• Examples:

• ulimit -Sc 0   Suppress core dumps
• ulimit -Sd 409600   Limit program data segment size
• ulimit -Sn 256   Limit number of open file descriptors

• ulimit -Su 1024   Limit umber of processes/user

• MacOS weirdness: running an external command after setting ulimit -Sf causes the limit to be set to unlimited. This is true only for the -Sf

• $ ulimit -Sf 409600; ulimit-f; /bin/echo 'WTF?'; ulimit -f
• 4096000
• WTF?

• unlimited

• There is also a prlimit command to show per-process limits

Presentation: PostgreSQL

Features

• Multi-version concurrency control (MVCC)
• Point in time recovery
• Ansynchronous replication
• Nested transactions
• Hot backups
• Write-ahead Logging (and it works on logging filesystems)
• International character sets and collations
• Full Unicode support
• Geomatic Information Systems (GIS)
• Full-text search
• Multi-petabyte scalability (using clusters; multi-terabyte on a single server)

When should you switch to PostgreSQL?

• MySQL workload is no longer read-bound or write-bound (it doesn’t like mixed read/write environments)
• Database engine needs to fit into less memory
• Existing database query optimizer is not sophisticated enough to handle increasingly complex reporting
• GIS features require expensive add-on
• User licensing requirements require expensive upgrade (we’re looking at you, Oracle!)
• Can’t distribute GPL source code with your closed-source product
• New projects: why would you use anything else?

Where to use PostgreSQL?

• Embedded systems - PgSQL uses the OS buffer cache insetad of reserving its own memory
• Application-backing database - PgSQL requires zero maintenance out of the box. Nothing grows without bound unexpectedly.
• Large databases - the query optmizer is extremely intelligent
• Hybrid systems - PgSQL is natively both an object database (XML, JSON, maybe LDAP?) and an RDBMS
• GIS systems: PostGIS rivals or betters all commercial competitors
• ORACLE replacement - EnterpriseDB Advanced Server is a compile-time replacement for ORACLE RDBMS