日常搬砖，总少不了需要获取分页数据和总行数。一直以来的实践是编码两次sql请求，分别拉分页数据和totalCount。最近我在思考：常规实践为什么不是 在一次sql请求中中执行多次sql查询或多次更新，显而易见的优势：① 能显著减低“客户端和服务器之间的网络往返次数”，提高吞吐量② 简化客户端代码逻辑1. mysql 默认单sql请求单语句mysql客户端选项client_multi_statem

前言现代计算机基于计算、存储和调度的体系， 于是现代架构都是围绕这三大话题不断演进。在基础架构部， 也是主要为了解决这三个难题，为业务事业部提供透明的、高可用、可快速伸缩的三大能力， 我们组主要负责 [流量调度] 这个话题,下面是一些宏观的技术笔记。在单体结构， 流量调度是直观且无感的(DNS+Nginx就可以完成一次流量调度)。演进到微服务结构（服务粒度变得更细、服务伸缩更灵活(上下线更加频繁)

业务方反应调用接口超时，但是在服务端监控并没有看到5xx异常， 于是我们模拟一下请求超时时发生了什么？1.openresty模拟长耗时服务端延迟5s响应error_loglogs/error.log;http{server{listen80;charsetutf-8;location/reqtimeout{...

点击蓝色“Dotnet Plus”关注我哟加个“星标”，每天清晨07:25，干货推送！作为一枚后端程序狗，项目实践常遇到定时任务的工作，最容易想到的的思路就是利用Windows计划任...

二进制中，除1/2=0.5，1/4=0.25，1/8=0.125，1/2+1/8=0.625等在计算机中能精确存储， 其他数字（eg：0.1，0.2，0.3）都不能精确存储.MoE专家架构，总参数是122B， 激活参数10B（每次推理用到的参数），但是总参数要都加载进显存。， 参考上面的场景③。场景③ 其余的 0.1，0.2，0.3，0.314等是有限小数， 口语一般不涉及精度，保持原数。只要小数

当部署pod时，可以在pod manifest文件指定自定义的Scheduler， 这样调度器的调度决定就会基于你自定义的调度逻辑。从本质上讲，它会利用pod规格（cpu、memory、亲和性、污点、持久盘）过滤掉不适合运行特定pod的节点。pod priority： 高优先级的pod通过影响打分过程影响节点选择（高优Pod会先于低优Pod被调度）。pod拓扑分布： 确保 pod 分布在不同的拓扑

是一个同步的函数，持续执行list-watch-cache-react这个引擎， 在应用层面需要以子goroutine形式，client-go另有informer工厂，informerFactory.Start(stopCh) 内部也是启协程，这里也要认识到信道stopCh在golang中的通信作用。运行一个完整的informer： list ---> watch ---> cache---> r

对idc内各种异构计算（GPU、CPU、NPU等）、存储（OSS、NAS、CPFS、HDFS）、网络（TCP、RDMA）资源进行抽象，统一管理和运维和分配，通过软硬协同优化，提供资源利用率。从异构资源管理的角度，可一键部署、操作各种异构资源，在运维过程中，需要多维度的异构资源可观测性： 监控、健康检查、告警、自愈等自动化运维能力。提供弹性训练和弹性推理服务， 建立统一的数据集管理，模型生命周期管理

无论是agentic开发，使用LLM APi， 理解function calling 都很重要，特别是底层的请求和响应payload工作方式。ollama是服务端-客户端架构，有后台服务进程olllama.exe，提供了GUI终端和命令行工具可交互，另外提供sdk和restful api，可供各种程序或者语言操作ollama。首次推理请求， 显存使用稳定在6g, gpu使用率上升，推理结束，显存使

是一个同步的函数，持续执行list-watch-cache-react这个引擎， 在应用层面需要以子goroutine形式，client-go另有informer工厂，informerFactory.Start(stopCh) 内部也是启协程，这里也要认识到信道stopCh在golang中的通信作用。运行一个完整的informer： list ---> watch ---> cache---> r