commit
This commit is contained in:
parent
f78bb9f547
commit
c8fb1d5c74
@ -281,6 +281,22 @@ docker run -p 8080:8080
|
|||||||
--link=[]: 添加链接到另一个容器;
|
--link=[]: 添加链接到另一个容器;
|
||||||
--expose=[]: 开放一个端口或一组端口;
|
--expose=[]: 开放一个端口或一组端口;
|
||||||
--volume , -v 绑定一个卷
|
--volume , -v 绑定一个卷
|
||||||
|
--restart:重启策略:
|
||||||
|
|
||||||
|
- **`no`** – 此策略永远不会自动启动容器。这是使用 `docker run` 创建的所有容器的默认策略。
|
||||||
|
- **`always`** – Docker 将确保容器始终运行。如果容器停止,它将立即重新启动。您仍然可以使用 `docker stop` 手动停止容器,但 Docker 会在下次守护进程重新启动时将其恢复。
|
||||||
|
- **`on-failure`** – 如果容器因错误而停止,它将重新启动。守护进程重启后,Docker 不会启动容器。
|
||||||
|
|
||||||
|
`on-failure` 重启策略允许您指定应尝试重试的次数。如果连续多次启动失败,Docker 将放弃并让容器处于停止状态。
|
||||||
|
|
||||||
|
```sql
|
||||||
|
docker run httpd:latest --restart on-failure:5
|
||||||
|
```
|
||||||
|
|
||||||
|
在此示例中,Docker 将在失败(非零退出代码)后尝试重新启动容器五次。如果容器在第五次尝试时启动失败,将不再尝试重试。此选项对于在没有手动干预的情况下不太可能解决持续启动错误的容器很有用。
|
||||||
|
- **`unless-stopped`** – 其功能类似于`always`。不同之处在于,如果容器已被手动停止,Docker 将永远不会重新启动容器。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### 启动容器
|
### 启动容器
|
||||||
|
|
||||||
|
|||||||
@ -27,6 +27,42 @@ C:\Program Files\dotnet\sdk\9.0.302\Sdks\Microsoft.NET.Sdk.Publish\targets\Publi
|
|||||||
|
|
||||||

|

|
||||||
|
|
||||||
|
# IIS(Internet Information Services)
|
||||||
|
|
||||||
|
## 优化回收策略
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
- 回收 > 固定时间间隔(分钟)
|
||||||
|
|
||||||
|
一个时间段,超过该时间段,应用程序池将回收。值为 0 ,则应用程序池不会按固定间隔回收
|
||||||
|
|
||||||
|
默认值:1740分钟,29小时
|
||||||
|
|
||||||
|
优化设置:改为0 。因为无法避免在高峰期发生回收。同时设置“回收 > 特定时间”
|
||||||
|
|
||||||
|
- 回收 > 特定时间
|
||||||
|
|
||||||
|
应用程序池进行回收的一组特定的本地时间(24小时制)
|
||||||
|
|
||||||
|
优化设置:固定在低峰期时回收。eg:设定为 04:00 、15:30 等
|
||||||
|
|
||||||
|
另外,也可以使用windows计划任务实现iis站点每周六晚定时回收
|
||||||
|
|
||||||
|
- 进程模型 > 闲置超时(分钟)
|
||||||
|
|
||||||
|
一个时间段,设定工作进程允许保持闲置状态的最大时间间隔,超过该时间就会自动关闭。
|
||||||
|
|
||||||
|
优化设置:改为0,避免内存信息频繁被回收清空。同时设置“回收 > 特定时间”
|
||||||
|
|
||||||
|
- 进程模型 > 空闲超时操作
|
||||||
|
|
||||||
|
默认是“Terminate”(另一个选项是“Suspend”)。
|
||||||
|
|
||||||
|
Terminate 表示一旦超时就终止服务,并回收工作进程的缓冲区的内存;
|
||||||
|
|
||||||
|
Suspend 则悬停等待,暂不回收缓冲区内存。
|
||||||
|
|
||||||
# Windows 运行命令
|
# Windows 运行命令
|
||||||
|
|
||||||
## 进入Windows 设置
|
## 进入Windows 设置
|
||||||
|
|||||||
@ -337,6 +337,16 @@ modelscope download --model 'Qwen/Qwen2-7b' --include '*.json' --local_dir './lo
|
|||||||
|
|
||||||
如果`cache_dir`和`local_dir`参数同时被指定,`local_dir`优先级高,`cache_dir`将被忽略。
|
如果`cache_dir`和`local_dir`参数同时被指定,`local_dir`优先级高,`cache_dir`将被忽略。
|
||||||
|
|
||||||
|
### 环境变量配置
|
||||||
|
|
||||||
|
#### 默认下载目录
|
||||||
|
|
||||||
|
指定`modelscope`默认下载目录为`/AI/modelscope/hub`
|
||||||
|
|
||||||
|
```bash
|
||||||
|
echo 'export MODELSCOPE_CACHE=/AI/modelscope/hub' >> ~/.bashrc
|
||||||
|
```
|
||||||
|
|
||||||
# Anaconda
|
# Anaconda
|
||||||
|
|
||||||
>
|
>
|
||||||
@ -937,3 +947,30 @@ print(f'Model is quantized and saved at "{quant_path}"')
|
|||||||
- **Hybrid-MoE**:折中方案,平衡性能与成本,需精细调优。
|
- **Hybrid-MoE**:折中方案,平衡性能与成本,需精细调优。
|
||||||
|
|
||||||
实际选型需结合**任务需求**、**硬件资源**和**工程能力**综合评估。对于大多数企业级应用,Hybrid-MoE可能是当前的最优解,而科研前沿更倾向于探索纯MoE的极限能力。
|
实际选型需结合**任务需求**、**硬件资源**和**工程能力**综合评估。对于大多数企业级应用,Hybrid-MoE可能是当前的最优解,而科研前沿更倾向于探索纯MoE的极限能力。
|
||||||
|
|
||||||
|
# Dify
|
||||||
|
|
||||||
|
## Dify 向量存储机制简述
|
||||||
|
|
||||||
|
在 Dify 中,文档数据(如知识库文档、FAQ、手册等)需要经过向量化处理,才能用于语义检索和问答增强。其核心处理流程如下图所示:
|
||||||
|
|
||||||
|
```
|
||||||
|
文档(原始文本)
|
||||||
|
↓
|
||||||
|
Embedding(由 OpenAI, Hugging Face, etc. 提供)
|
||||||
|
↓
|
||||||
|
向量(高维 float 数组)
|
||||||
|
↓
|
||||||
|
Vector Store(默认为 Weaviate)
|
||||||
|
↓
|
||||||
|
Dify 查询时执行语义检索,返回匹配片段
|
||||||
|
```
|
||||||
|
|
||||||
|
向量存储的作用
|
||||||
|
|
||||||
|
Dify 本身不负责存储嵌入向量,而是通过调用第三方向量数据库来管理这些向量。向量数据库的主要职责包括:
|
||||||
|
|
||||||
|
- 存储文本对应的向量数据(float 数组)
|
||||||
|
- 为每条向量建立索引,支持高效近似/精确搜索
|
||||||
|
- 提供语义检索 API(如 top-k 相似度查找)
|
||||||
|
- 支持元数据管理(如 document_id, source, tags 等)
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user