首页 > 解决方案 > 吞吐量的操作系统计算

问题描述

我可以得到帮助吗?我似乎无法理解这个问题

“在这个问题中,您将比较使用单线程文件服务器和多线程文件服务器读取文件。假设需要 16 毫秒来获取工作请求、调度它并执行其余必要的处理"

标签: operating-system

解决方案


我可以得到帮助吗?

我不这么认为(我认为问题中没有足够的信息让任何人都能够理解它)。

示例 1

文件服务器是单线程的,处理异步请求,“16毫秒”主要是“请求传递延迟”(从进程发送请求到文件服务器接收请求的时间)。一个进程发送一个请求读取 1000 个文件,文件服务器收到这个请求,“立即”发回 750 个回复(对于缓存的文件数据)并发送一个请求(文件系统代码,磁盘驱动程序? ) 获取剩余的 250 个东西;然后文件服务器“立即”等待更多请求,同时等待来自某些东西(文件系统代码,磁盘驱动程序?)的回复以完成早期的 250 件事情。在这种情况下,您可以说单线程文件服务器的吞吐量实际上是无限的(例如“文件数据缓存命中”的无限吞吐量

示例 2

文件服务器有 8 个线程并处理同步请求。单线程进程发送 1 个请求(从 1 个文件读取),然后必须等待回复,请求被提供给文件服务器的一个线程(不管哪个线程),该线程平均需要 " 16 + 32*0.25 = 24 毫秒”,用于在进程发出下一个请求之前处理请求;并且该进程循环执行此操作,因为它要读取 1000 个文件。在这种情况下,吞吐量是“每秒 1/0.024 = 41.66 个请求”,这是非常糟糕的(主要是因为单线程进程无法足够快地发送请求以保持多线程服务器的所有线程都忙)。

示例 3

文件服务器有 8 个线程并处理同步请求。具有 1000 个线程的进程从其每个线程发送 1 个请求(从 1 个文件中读取)。在这种情况下,我们需要知道有多少 CPU(以及调度程序如何工作)来确定有关吞吐量的任何信息。例如,如果只有 2 个 CPU,那么您将不会让 8 个文件服务器线程同时并行运行。


推荐阅读