| If you redis initial replication fails with error like | |
| "5101:M 20 Feb 18:14:29.130 # Client id=4500196 addr=71.459.815.760:43872 fd=533 name= age=127 idle=127 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=13997 oll=1227 omem=192281275 events=rw cmd=psync scheduled to be closed ASAP for overcoming of output buffer limits. | |
| means that slave buffer is not enough and you should increase it (at master!) with command like | |
| redis-cli config set client-output-buffer-limit "slave 836870912 836870912 0" | |
| more info: https://redis.io/topics/clients |
In response to this brief blog entry, @antirez tweeted for some documentation on high-performance techniques for Redis. What I present here are general high-performance computing (HPC) techniques. The examples are oriented to Redis. but they work well for any program designed to be single- or worker-threaded and asynchronous (e.g. uses epoll).
The motivation for using these techniques is to maximize performance of our system and services. By isolating work, controlling memory, and other tuning, you can achieve significant reduction in latency and increase in throughput.
My perspective comes from the microcosm of my own bare-metal (vs VM), on-premises deployment. It might not be suitable for all scenarios, especially cloud deployments, as I have little experience with HPC there. After some discussion, maybe this can be adapted as [redis.io documentation](https://redis.io/do
The Linux kernel is written in C, so you should have at least a basic understanding of C before diving into kernel work. You don't need expert level C knowledge, since you can always pick some things up underway, but it certainly helps to know the language and to have written some userspace C programs already.
It will also help to be a Linux user. If you have never used Linux before, it's probably a good idea to download a distro and get comfortable with it before you start doing kernel work.
Lastly, knowing git is not actually required, but can really help you (since you can dig through changelogs and search for information you'll need). At a minimum you should probably be able to clone the git repository to a local directory.
Please check https://aws.github.io/aws-eks-best-practices/ for more comprehensive EKS best practice!
- Think about multi-tenancy, isolation for different environment or different workload
- Isolation at account level using AWS organization
- Isolation at the network layer ie. different VPC & different cluster
- Use different Nodes Group (Node pool) for different purpose/category e.g. create dedicated node groups for Operational tools such as CI/CD tool, Monitoring tool, Centralize logging system.
- Separate namespace for different workload