linux I/O优化 磁盘读写参数设置

本文介绍了 Linux 下 I/O 性能调优的方法,包括页面缓存、pdflush 进程、文件系统缓冲、I/O 调度器等关键参数的解释及调整建议。

转载:http://wlservers.blog.163.com/blog/static/120622304201241715945256/


关于页面缓存的信息,可以用
cat /proc/meminfo 
看到。其中的Cached 指用于pagecache的内存大小(diskcache-SwapCache)。随着写入缓存页,Dirty 的值会增加。
一旦开始把缓存页写入硬盘,Writeback的值会增加直到写入结束。

Linux 用pdflush进程把数据从缓存页写入硬盘,查看有多少个pdflush进程
cat /proc/sys/vm/nr_pdflush_threads

pdflush的行为受/proc/sys/vm中的参数的控制
/proc/sys/vm/dirty_writeback_centisecs (default 500): 
1/100秒, 多长时间唤醒pdflush将缓存页数据写入硬盘。默认5秒唤醒2个(更多个)线程。
如果wrteback的时间长于dirty_writeback_centisecs的时间,可能会出问题。

pdflush的第一件事是读取
/proc/sys/vm/dirty_expire_centiseconds (default 3000)
1/100秒。缓存页里数据的过期时间(旧数据),在下一个周期内被写入硬盘。默认30秒是一个很长的时间。

第二件事是判断内存是否到了要写入硬盘的限额,由参数决定:
/proc/sys/vm/dirty_background_ratio (default 10)
百分值,保留过期页缓存(脏页缓存)的最大值。是以MmeFree+Cached-Mapped的值为基准的

pdflush写入硬盘看两个参数:
1 数据在页缓存中是否超出30秒,如果是,标记为脏页缓存;
2 脏页缓存是否达到工作内存的10%;

以下参数也会影响到pdflush
/proc/sys/vm/dirty_ratio (default 40)
总内存的最大百分比,系统所能拥有的最大脏页缓存的总量。超过这个值,开启pdflush写入硬盘。如果cache增长快于pdflush,那么整个系统在40%的时候遇到I/O瓶颈,所有的I/O都要等待cache被pdflush进硬盘后才能重新开始。

对于有高度写入操作的系统
dirty_background_ratio: 主要调整参数。如果需要把缓存持续的而不是一下子大量的写入硬盘,降低这个值。
dirty_ratio:        第二调整参数。

Swapping参数
/proc/sys/vm/swappiness
默认,linux倾向于从物理内存映射到硬盘缓存,保持硬盘缓存尽可能大。未用的页缓存会被放进swap区。
数值为0,将会避免使用swapping
100,将会尽量使用swapping
少用swapping会增加程序的响应速度;多用swapping将会提高系统的可用性。

如果有大量的写操作,为避免I/O的长时间等待,可以设置:
$ echo 5 > /proc/sys/vm/dirty_background_ratio
$ echo 10 > /proc/sys/vm/dirty_ratio

文件系统数据缓冲需要频繁的内存分配。加大保留内存的值能提升系统速度和稳定。小于8G的内存,保留内存为64M,大于8G的设置为256M
$ echo 65536 > /proc/sys/vm/min_free_kbytes


I/O 调度器
cat /sys/block/[disk]/queue/scheduler

4中调度算法
noop anticipatory deadline [cfq] 
deadline :    deadline 算法保证对既定的IO请求以最小的延迟时间。
anticipatory:    有个IO发生后,如果又有进程请求IO,则产生一个默认6ms猜测时间,猜测下一个进程请求IO是干什么。这对于随机读取会造成较大的延时。
        对数据库应用很糟糕,而对于Web Server等则会表现不错。
cfq:        对每个进程维护一个IO队列,各个进程发来的IO请求会被cfq以轮循方式处理,对每一个IO请求都是公平。适合离散读的应用。
noop:        对所有IO请求都用FIFO队列形式处理。默认IO不会存在性能问题。

改变调度器
$ echo deadline > /sys/block/sdX/queue/scheduler
对于数据库服务器,deadline算法是推荐的。

提高调度器请求队列的
$ echo 4096 > /sys/block/sdX/queue/nr_requests

有大量的读请求,默认的请求队列应付不过来,可以提高这个值。缺点是要牺牲一定的内存。
为了增加连续读取的吞吐量,可以增加预读数据量。预读的实际值是自适应的,所以使用一个较高的值,不会降低小型随机存取的性能。
$ echo 4096 > /sys/block/sdX/queue/read_ahead_kb
如果LINUX判断一个进程在顺序读取文件,那么它会提前读取进程所需文件的数据,放在缓存中。
  


服务器遇到磁盘写活动高峰,导致请求处理延迟非常大(超过3秒)。通过调整内核参数,将写活动的高峰分布成频繁的多次写,每次写入的数据比较少。这样可以把尖峰的写操作削平成多次写操作。以这种方式执行的效率比较低,因为内核不太有机会组合写操作。但对于繁忙的服务器,写操作将更一致地进行,并将极大地改进交互式性能。

/proc/sys/vm/dirty_ratio

控制文件系统的写缓冲区的大小,单位是百分比,表示占系统内存的百分比,表示当写缓冲使用到系统内存多少的时候,开始向磁盘写出数据。增大之会使用更多系统内存用于磁盘写缓冲,也可以极大提高系统的写性能。但是,当你需要持续、恒定的写入场合时,应该降低其数值。
/proc/sys/vm/dirty_background_ratio
控制文件系统的pdflush进程,在何时刷新磁盘。单位是百分比,表示系统内存的百分比,pdflush用于将内存中的内容和文件系统进行同步,比如说,当一个文件在内存中进行修改,pdflush负责将它写回硬盘.每当内存中的垃圾页(dirty page)超过10%的时候,pdflush就会将这些页面备份回硬盘.增大之会使用更多系统内存用于磁盘写缓冲,也可以极大提高系统的写性能。但是,当你需要持续、恒定的写入场合时,应该降低其数值:
/proc/sys/vm/dirty_writeback_centisecs
控制内核的脏数据刷新进程pdflush的运行间隔。单位是 1/100 秒。缺省数值是500,也就是 5 秒。如果你的系统是持续地写入动作,那么实际上还是降低这个数值比较好,这样可以把尖峰的写操作削平成多次写操作。
如果你的系统是短期地尖峰式的写操作,并且写入数据不大(几十M/次)且内存有比较多富裕,那么应该增大此数值。
该参数的设置应该小于dirty_expire_centisecs,但也不能太小,太小I/O太频繁,反而
使系统性能下降。具体可能需要在生产环境上测试。据说1:6 (dirty_expire_centisecs  : dirty_writeback_centisecs )的比例比较好。

/proc/sys/vm/dirty_expire_centisecs

声明Linux内核写缓冲区里面的数据多“旧”了之后,pdflush进程就开始考虑写到磁盘中去。单位是 1/100秒。缺省是 30000,也就是 30 秒的数据就算旧了,将会刷新磁盘。对于特别重载的写操作来说,这个值适当缩小也是好的,但也不能缩小太多,因为缩小太多也会导致IO提高太快。
当然,如果你的系统内存比较大,并且写入模式是间歇式的,并且每次写入的数据不大(比如几十M),那么这个值还是大些的好。

/proc/sys/vm/vfs_cache_pressure

表示内核回收用于directory和inode   cache内存的倾向;缺省值100表示内核将根据pagecache和swapcache,把directory和inode   cache保持在一个合理的百分比;降低该值低于100,将导致内核倾向于保留directory和inode   cache;增加该值超过100,将导致内核倾向于回收directory和inode   cache

/proc/sys/vm/min_free_kbytes

表示强制Linux   VM最低保留多少空闲内存(Kbytes)。
缺省设置:724(512M物理内存)

/proc/sys/vm/nr_pdflush_threads

表示当前正在运行的pdflush进程数量,在I/O负载高的情况下,内核会自动增加更多的pdflush进程。
/proc/sys/vm/overcommit_memory
指定了内核针对内存分配的策略,其值可以是0、1、2。

0,   表示内核将检查是否有足够的可用内存供应用进程使用;如果有足够的可用内存,内存申请允许;否则,内存申请失败,并把错误返回给应用进程。

1,   表示内核允许分配所有的物理内存,而不管当前的内存状态如何。

2,   表示内核允许分配超过所有物理内存和交换空间总和的内存(参照overcommit_ratio)。

缺省设置:0
/proc/sys/vm/overcommit_ratio
如果overcommit_memory=2,可以过载内存的百分比,通过以下公式来计算系统整体可用内存。系统可分配内存=交换空间+物理内存*overcommit_ratio/100
缺省设置:50(%)

/proc/sys/vm/page-cluster

表示在写一次到swap区的时候写入的页面数量,0表示1页,1表示2页,2表示4页。
缺省设置:3(2的3次方,8页)
/proc/sys/vm/swapiness
表示系统进行交换行为的程度,数值(0-100)越高,越可能发生磁盘交换。

更改:
/etc/sysctl.conf

vm.dirty_ratio = 40

sysctl -p

查看:
find /proc/sys/vm  -name dirty*  -print   | while  read   name; do  echo $name ;cat ${name}; done

<think>我们正在讨论Gemini GenAI SDK中的聊天历史功能。由于这是一个特定的技术问题,我将根据一般性的知识和常见的SDK设计模式来回答,因为Gemini GenAI SDK的具体实现细节可能随时间变化,且我没有实时的访问权限。但我会尽量提供通用且可靠的指导。 聊天历史功能通常是指在一个持续对话中,模型能够记住之前的对话内容,从而在后续的回复中保持上下文。在Gemini GenAI SDK中,实现聊天历史管理通常涉及以下几个关键点: 1. **消息传递结构**:通常,每次调用模型时,我们需要传递整个对话历史(包括用户的消息和模型的回复)作为上下文。这样模型才能基于整个对话历史生成回复。 2. **消息格式**:每条消息通常包含角色(如"user"或"model")和内容(文本)。例如: ```json [ {"role": "user", "content": "你好"}, {"role": "model", "content": "你好!有什么可以帮助你的吗?"}, {"role": "user", "content": "告诉我Gemini是什么?"} ] ``` 3. **管理对话历史**:开发者需要维护一个消息列表,每次用户发送新消息时,将新消息添加到历史列表中,然后调用模型生成回复,再将模型的回复也添加到历史列表中。注意,历史记录的长度不能超过模型的最大上下文长度(通常有token限制)。 4. **截断历史记录**:当对话历史很长时,需要截断以避免超过token限制。常见的策略是保留最近的几条消息,或者删除中间的一些消息但保留开头(如系统指令)和最近的对话。 5. **Gemini SDK中的具体实现**:在Gemini SDK中,可能会有一个`ChatSession`类来管理对话状态。例如: ```python import google.generativeai as genai genai.configure(api_key="YOUR_API_KEY") model = genai.GenerativeModel(&#39;gemini-pro&#39;) chat = model.start_chat(history=[]) # 初始历史为空 response = chat.send_message("你好") print(response.text) # 模型的回复 # 继续对话 response = chat.send_message("告诉我Gemini是什么?") print(response.text) # 查看历史 for message in chat.history: print(message.role, message.parts[0].text) ``` 在上面的例子中,`chat`对象会自动维护历史记录。每次调用`send_message`后,用户的消息和模型的回复都会被添加到`chat.history`中。 6. **常见问题**: - **上下文丢失**:如果发现模型没有记住之前的对话,请检查是否在每次发送消息时都使用了同一个`ChatSession`实例,并且历史记录是否正确传递。 - **token限制**:当历史记录很长时,可能会超过模型的最大token限制(例如,gemini-pro模型的最大上下文长度是30720个token)。此时,需要手动截断历史记录(如保留最近的几条消息)或者使用更高级的摘要技术。 - **历史记录存储**:如果需要长期存储对话,可以将历史记录保存到数据库,并在下次对话时重新加载。但要注意,重新加载后,需要确保整个历史记录不超过token限制。 7. **重置历史**:如果需要开始一个新的对话,可以创建一个新的`ChatSession`实例。 8. **系统指令**:在对话开始时,可以设置一个系统指令(system instruction)来指导模型的行为。例如: ```python model = genai.GenerativeModel(&#39;gemini-pro&#39;, system_instruction="你是一个专业的客服助手。") ``` 以上是关于Gemini GenAI SDK中聊天历史功能的基本实现和常见问题处理。具体细节请参考官方文档。 由于这是一个技术性较强的问题,我生成的相关问题将围绕使用中的常见场景和问题: §§相关问题§§ 1. 如何在Gemini GenAI SDK中重置聊天历史? 2. 当对话历史很长时,如何避免超过模型的token限制? 3. 如何将聊天历史保存到数据库并在下次对话时恢复? 4. Gemini模型支持的最大上下文长度是多少? 5. 在Gemini SDK中,如何设置系统指令来指导模型的行为?</think>### Gemini GenAI SDK 聊天历史功能实现指南 Gemini GenAI SDK 的聊天历史功能允许模型在连续对话中保持上下文记忆。以下是关键实现步骤和常见问题解决方案: #### 一、核心实现方法 1. **历史记录传递** 每次请求需将完整对话历史作为上下文传入: ```python from google.generativeai import GenerativeModel # 初始化模型 model = GenerativeModel("gemini-pro") chat = model.start_chat(history=[]) # 初始历史为空 # 首次交互 response = chat.send_message("解释量子力学") print(response.text) # 模型回复 # 后续交互(自动携带历史) response = chat.send_message("用简单例子说明") print(response.text) # 基于上下文的回复 ``` 2. **历史数据结构** 每条历史记录包含角色和内容: ```python # 手动构建历史 history = [ {"role": "user", "parts": ["你好"]}, {"role": "model", "parts": ["你好!有什么可以帮助你?"]} ] ``` 3. **历史管理技巧** - **上下文长度限制**:Gemini 1.5 Pro 支持最大 1M token 上下文[^1] - **历史截断策略**: ```python # 保留最近10轮对话 if len(chat.history) > 20: # 10轮对话=20条消息 chat.history = chat.history[-20:] ``` #### 二、常见问题解决 1. **上下文丢失问题** **症状**:模型忘记之前的对话 **解决方案**: - 检查是否每次调用都传递了完整 `chat.history` - 验证 token 计数是否超限: ```python import tiktoken encoder = tiktoken.encoding_for_model("gpt-4") tokens = encoder.encode(str(chat.history)) print(len(tokens)) # 需小于模型上限 ``` 2. **历史记录污染** **场景**:用户输入包含敏感数据 **清理方法**: ```python def clean_history(history): return [msg for msg in history if not is_sensitive(msg["parts"][0])] ``` 3. **性能优化** - 使用 `stream=True` 流式传输减少延迟 - 对长历史启用摘要功能: ```python summary = model.generate_content("总结对话要点: " + str(history[-5:])) new_history = [{"role": "system", "parts": [summary.text]}] ``` #### 三、最佳实践 1. **混合历史策略** ```mermaid graph LR A[新对话] --> B{历史长度>阈值?} B -->|是| C[摘要前5轮+完整后5轮] B -->|否| D[使用完整历史] ``` 2. **元数据存储** 建议将历史记录与会话元数据(如 session_id)共同存储: ```python # Firebase 存储示例 firestore.collection("chats").document(session_id).set({ "history": chat.history, "last_updated": firestore.SERVER_TIMESTAMP }) ``` > **重要提示**:Gemini 1.5 支持原生文件处理(PDF/Word),可将文档作为历史上下文传入[^1]: > ```python > response = chat.send_message( > "总结此文档", > file=open("report.pdf", "rb") > ) > ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值