您正在查看 "默认分类" 分类下的文章 2011-05-30 8:37 最近在线上实际使用了一些redis服务,总结下运维的相关知识. 1:redis的生产机主要为2颗Cpu,8个核心,内存32G,单盘700G的Sata盘.
2:存储的数据为博客系统的积分数据.积分代表是用户的发文章积分,发评论积分,登录积分,特点即每天单个用户相关数据至多增加一次,是一个典型的读多写少系统.虽然在这个项目中将redis作为内存系统使用,本质上是落地存储.
3:redis版本为2.2.5,使用 |
2011-05-19 15:41 近半年一直在做服务迁移的事情,现在遇到一个问题,需要将WebServer从Nginx替换为Apache. 今天查阅了相关资料:Nginx+FastCgi+Php 的工作机制.
FastCgi是通讯协议,可以通过Unix套接字或者Tcp进行通讯.Nginx内置基本模块FastCgi模块(控制缓存区大小等功能) Nginx通过FastCgi技术和外部的服务或者工具一起工作.Php自己能够运行一个Fastcgi应用程序(php-fcgi).. Nginx通过FastCgi协议将请求发送给Php Fastcgi应用程序执行 编译Php的时候配置--enable-fastcgi.可以通过二种方法运行FastCgi Server |
2011-05-10 19:30 这三天看了高性能Mysql这本书的第七章-操作系统和硬件优化.
至于为什么看这章节,主要是因为最近一直在看操作系统原理这本书,是想通过了解具体的软件设计(比如Mysql)来进行思路的整理.
这章节不仅仅是优化,本身Mysql的设计也是借鉴了很多操作系统原理的知识,可以说假如了解了Mysql,那么学习其他的就可能融会贯通.
其实以前也看过这章节,但是到目前为止,基本上全忘了,所以说这有二方面原因:
1:不要假学习.
2:基础理论知识理解深刻了,才能更好的学习其他的,这也不是一个实践就能解决的问题.
其实 |
2011-04-21 19:06 视频的Cache层是使用Squid进行服务的,当然对于这样的缓存服务也有人使用Varish或者Nginx的Proxy Cache.但是经过一段时间的使用和了解,Squid确实有其强大指出,尤其在反代理这个方面.包括还有很多成熟的功能模块,对于视频这样重网络I/0和大文件存储的应用来说,某些参数的设置和模块确实比较重要.
1:视频拖动模块 支持视频的拖动,这个其实需要二次开发,但是应该不难.
2:视频业务一般都是做防刷的,一般通过变化URL进行控制,而Squid是通过URL进行缓存的,所以同一份内容可能会缓存多次,而Storeurl_rewrite就能
|
2011-04-20 18:51 1:智能IP调度 IP库提供了IP地址（段）同地理、ISP、结构等信息映射关系的一组数据。通过用户端的IP和IP库进行比较更加精准的定位用户.从统计的数据来看10%的用户下载速分率小于100KByte/s.对于实际的IP调度可能要根据用户实际的网络情况进行不断的调整.
2:码率大小
码率就是数据传输时单位时间传送的数据位数,一般用单位是kbps即千位每秒.
码率分为固定码率和可变码率.码率和清晰度是成正比的.提升码率对于视频容量和带宽都具有较大影响,而对于用户来说,需要考虑用户下行带宽和下载速率.没有想到一个方法来统 |
2011-04-14 18:21 上一篇博文统计了视频Squid的相关日志,从中也可以发现一些改造点 1:可以看出有15%的用户下载速率达到了1MByte/s.也就是用户在下载视频过程中,大部分视频文件10秒就能下载完成.那么这个说明了什么
(1) 极大浪费带宽,尤其对于大片,可能部分用户看了开头就直接关闭浏览器了.而实际视频文件已经下载下来了.等于极大浪费带宽.当然也有好处,比如用户拖动的时候其实直接在buffer中进行操作了,对用户的感受还是比较好的.
(2) 大部分用户的下载速率小于300KByte/s.而由于这些变态高速率用户会极大强制带宽资源,尤其对于单机来 |
2011-04-13 18:33 最近分析了下基于Squid的视频业务的日志,发现一些比较不错的内容:
1:很多视频网站或者静态类网站都用Squid作为前端的缓存.其实对于大容量对象来说,内存命中和磁盘命中对于用户的下载速率影响不大,但是需要基于一个前提:磁盘的吞吐能力处于可接受范围之内.一般I/O等待不要超过30.包括缓存命中和未命中下载速率也影响不大,因为内网的带宽是足够的(最终还是取决于磁盘性能).总体来说,视频类的静态服务取决于磁盘的读写性能.
2:影响视频类服务质量最大的因素是带宽.一旦出口带宽不够(主要是高峰时刻),则影响的不仅
|
2011-04-11 9:05 对于数据分析的态度，有几句牢骚要发泄一下，纯属这几年工作的个人心里感受。 面试后的感想 |
2011-02-26 16:21
进程:
Cpu能够处理多个请求,在于操作系统通过多执行流体系设计使得多个任务可以轮流使用资源.
多执行流的一般实现是进程,多进程的好处首先在于Cpu时间的轮流使用,另外对于Cpu计算和I/O(磁盘和网路I/O)操作进行了重叠
大多数进程的时间消耗在I/O操作上.DMA技术可以让Cpu不参与I/O操作的全过程,比如进程通过系统调用,使得Cpu
向网卡等设备发出指令,然后进程挂起,Cpu资源释放,等待I/O完成操作后通过中断告之进程重新就绪.
进程有自己的地址空间和生命周期.进程维护着庞大的地址空间和上下文信息,无法共享数据,所
|
2011-02-22 19:10 I/O模型:
I/O操作需要内核系统调用来完成,系统调用需要Cpu来调度,而Cpu的访问速度相对于I/O来说比较快,所以Cpu不得不浪费Cpu时间来等待慢速I/O操作.
通过多进程方式来充分利用CPU资源,当还是希望让Cpu花费少的时间在I/O操作的调度上,这样就可以有更多的Cpu来完成I/O操作.
很多技术和策略都围绕如何让高速的Cpu和慢速的I/O设备更好的协调工作.
I/O操作主要是网络数据的接收和发送,以及磁盘文件的访问.归纳为多种模型称为I/O模型,本质区别在于Cpu的参与方式.
PIO和DMA:
慢速I/O设备和内 |
2011-01-27 1:03 这一周在考虑冷热数据的二期，分析了多个维度的数据，感觉有点乱，记录一下。
我们的后端存储主要依赖于数据库(博文)，一般根据业务和功能进行分库/分表的拆分，来保持数据库实例的大小.在现实中遇到一系列的问题：
1)文章信息,包括文章内容都存储在一块.所以单个数据库记录非常的大.
2)理论上来说当数据库量越来越大的时候,理论上可以分库分表进行进一步分摊,但是实际上这个操作影响极大,包括程序的调整,服务的暂停.从目前我们的情况来看,已经不太建议使 |
2010-12-22 8:37 很久没更新博文了,主要还是觉得自己的思维没有进一步提高,今天简单记录下,以前总是以正向的方式去思考问题,其实对自己进行一些反向的思考收获可能更大.
修改了下原文,原来有些话说的有点太感性,希望对于看到的人有帮助.
1:对于Squid的使用思考
缓存服务目前有很多种,可能并没有很多人意识到为什么用Squid或者Memcached.他们解决的应用场景其实不一样的.期望用缓存解决所有复杂的事情,其实带来的管理代价是无穷的.通过最近的分析发现,只要是用户被动触发打开的页面,其命中率都不会很高,比如有多少人会去点文章第二页 |
2010-10-31 0:07 今天看了2个ppt:Velocity 2010 Highlights和Scalability, Availability & Stability Patterns
强调性能是网站第一要素,转换率,弹出率,页面PV均有变化.
你通过何种途径了解你的系统,什么样类型的产品,目的.监控的重点重要的是时间和关键路径.尤其强调了对人的优化,所以后续的优化需要针对用户的感觉(反过来说明技术并不是非常重要).
强调了运维人员的重要,运维核心的二个工作是自动化,你对你管理机器,进行的变更均需要记录,备份,自动,回滚,监控.随时要应付故障,运维人员第二个工作是需 |
2010-10-28 17:58 想成为架构师吗,先学习AWK。想提高效率吗，先学习AWK。
1:模式和操作
awk脚本由模式和操作组成,模式包括正则表达式,关系表达式,模式匹配表达式,模式,BEGIN,END.
操作由命令,函数,表达式组成,之 |
2010-10-27 10:48 | | |
