cirocosta / stress Goto Github PK

to get over this:

   RLIMIT_SIGPENDING (since Linux 2.6.8)
          Specifies  the limit on the number of signals that may be queued for the real user ID of the calling process.  Both standard and real-time signals are counted for the purpose
          of checking this limit.  However, the limit is enforced only for sigqueue(3); it is always possible to use kill(2) to queue one instance of any of the signals  that  are  not
          already queued to the process.

Typing any stress command for example, docker run cirocosta/stress mem -n 1024

gives this result:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: "mem": executable file not found in $PATH": unknown.

server: N-threads event-based (epoll) just accepting our pre-made payload and nothing more with cpu-affinity on each of these threads.
client: minimal http 1.1 complient chunk (totally static w/ in-memory fd sending with splice - see http://man7.org/linux/man-pages/man2/vmsplice.2.html). We can probably epoll on these writes and use the same idea as in the server

What are we looking for?

• how much we lose on middleware processing (haproxy)
• affects that this can make to the lb in terms of QoS

stress the default /proc/sys/fs/inotify/max_user_watches.