REDIS服务器系统呼叫上下文开关统计

发布于 2025-01-20 10:35:52 字数 1354 浏览 3 评论 0原文

官方文章引入redis pipelining强调read read（）） write（）系统调用对请求处理具有巨大的负面影响，因为上下文开关：

管道上不仅是减少与往返时间相关的延迟成本的一种方法，而且实际上可以大大提高您在给定的Redis服务器中每秒执行的操作数量。这是因为不使用管道，从访问数据结构并产生答复的角度来服务每个命令非常便宜，但是从执行插座I/O的角度来看，这是非常昂贵的。这涉及调用read（）和write（）syscall，这意味着要从用户土地到内核土地。上下文开关是巨大的速度罚款。

然后，我使用JEDIS对远程Redis服务器进行了基准测试，并具有100和200并发线程的连接池。结果QPS约为400。从理论上讲，在REDIS服务器上执行的上下文开关数应为800，如果每个read（）上下文开关，如

当内核代表用户执行系统调用时，可能会发生上下文开关...通常，即使系统调用没有阻止，内核也可以决定执行上下文开关，而不是返回控制呼叫过程。

但是，我使用pidstat命令仅观察到大约280个上下文切换：

11:32:07 AM   UID      TGID       TID   cswch/s nvcswch/s  Command
11:32:10 AM     0    148993         -    286.00      0.00  redis-server
11:32:10 AM     0         -    148993    286.00      0.00  |__redis-server
11:32:10 AM     0         -    148994      0.00      0.00  |__bio_close_file
11:32:10 AM     0         -    148995      0.00      0.00  |__bio_aof_fsync
11:32:10 AM     0         -    148996      0.00      0.00  |__bio_lazy_free
11:32:10 AM     0         -    148997      0.33      0.00  |__jemalloc_bg_thd

我想知道这是否是由于操作系统对Redis Server或其他因素使用的NIO机制进行的任何优化。如果有人能提供帮助，我将不胜感激！

原文

The official article introducing Redis pipelining emphasis that the read() and write() system call has a huge negative impact on request processing because of context switch:

Pipelining is not just a way to reduce the latency cost associated with the round trip time, it actually greatly improves the number of operations you can perform per second in a given Redis server. This is because without using pipelining, serving each command is very cheap from the point of view of accessing the data structures and producing the reply, but it is very costly from the point of view of doing the socket I/O. This involves calling the read() and write() syscall, that means going from user land to kernel land. The context switch is a huge speed penalty.

I then made a benchmarking against a remote Redis server, using Jedis, with a connection pool of size 100 and 200 concurrent threads. The result QPS is about 400. Theoretically the number of context switch executed on Redis server per second should be about 800, if every read() and write() syscall involves a context switch, as stated in computer systems: a programmer's perspective:

A context switch can occur while the kernel is executing a system call on behalf of the user...In general, even if a system call does not block, the kernel can decide to perform a context switch rather than return control to the calling process.

However, I observed about only 280 context switch per second using the pidstat command:

11:32:07 AM   UID      TGID       TID   cswch/s nvcswch/s  Command
11:32:10 AM     0    148993         -    286.00      0.00  redis-server
11:32:10 AM     0         -    148993    286.00      0.00  |__redis-server
11:32:10 AM     0         -    148994      0.00      0.00  |__bio_close_file
11:32:10 AM     0         -    148995      0.00      0.00  |__bio_aof_fsync
11:32:10 AM     0         -    148996      0.00      0.00  |__bio_lazy_free
11:32:10 AM     0         -    148997      0.33      0.00  |__jemalloc_bg_thd

I wonder if this is due to any optimizations conducted by the operating system, on the NIO mechanism used by Redis server or other factors. I would be appreciated if anyone can help!

分享到QQ

分享到微博