技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统运维
    在web项目中,大家都已经非常熟悉其架构流程了。这些流程中,几乎每个环节都会进行cache。从浏览器到webserver,到cgi程序,到DB数据库,会进行浏览器cache,数据cache,SQL查询的cache等等。对于fastcgi这里的cache,很少被使用。在我的测试过程中,发现一些问题。比如nginx的fastcgi_cache没缓存这条http响应,是因为响应头里包含“Expires”、“Cache-Control”的原因吗?程序里并没有输出“Expires”、“Cache-Control” http header的代码,这是谁输出的呢?既然是fpm响应的时候,就已经有了,那么是php的core模块,还是其他拓展模块输出的?
    这是在公司做的一个分享,目的是帮助新手快速的配置好python开发环境。在操作之前,建议先把你自己的vim配置文件(vimrc)和.vim文件夹先剪切到一个备份文件中。
    前几天 纯上 同学问了一个问题: 我ps aux看到的RSS内存只有不到30M,但是free看到内存却已经使用了7,8G了,已经开始swap了,请问ps aux的实际物理内存统计是不是漏了哪些内存没算?我有什么办法确定free中used的内存都去哪儿了呢? 这个问题不止一个同学遇到过了,之前子嘉同学也遇到这个问题,内存的计算总是一个迷糊账。
    在这里,我们将讲述TeamToy的理念、安装、基本功能的最佳实践、移动客户端、如何对接其他系统、以及插件的使用和开发。我们希望每个架设TeamToy的负责人都抽时间读一读这篇文章,它将帮你自上而下的去理解TeamToy,同时也提到了经常遇到的问题,让你在实际使用中会更加顺利。
    Sentry是个很好用的错误日志服务器,可以将程序错误的详细情况集中捕获,并提供一个很漂亮的Web界面来浏览错误。 Sentry本身是用python写的,但它支持python、php、ruby、iOS等多种语言。 要使用Sentry,你需要一台服务器来运行Sentry服务器,然后需要在代码中插入Sentry客户端的代码。
    最近公司服务器不太稳定,总是在凌晨某个时段突发高负载情况,因为客观环境比较复杂,所以很难猜测出到底是哪个进程出现了问题,加之故障发生时,通常我在睡觉,无形中增加了解决问题的难度,于是我便写了一个Shell来替我搞定这个问题。 实际上解决问题的思路非常简单:通过CRON每分钟运行一个Shell,查询系统负载,一旦发现异常,就通过「ps」命令保存进程快照,也可以进一步保存负载,内存等相关的数据,但通常没有必要,因为通过「sar」命令很容易拿到。
    在Linux下,如果你使用 java.security 包中的方法(比如SecureKeyFactory.generateSecret()),会发现它出奇的慢,有时候甚至是半僵死在那里。 有两个方法解决这个问题....
    一般在/etc/security/limits.conf 中修改最大打开文件数和进程数,如: * soft noproc 10240 * hard noproc 10240 * soft nofile 10240 * hard nofile 10240 但是在CentOS 6.3下,noproc的设置无效。需要修改/etc/security/limits.d/90-nproc.conf, 把noproc的设置放在这个文件里,重启服务器后,就生效了。
    为什么要使用ntpd而不是ntpdate? 原因很简单,ntpd是步进式的逐渐调整时间,而ntpdate是断点更新,比如现在服务器时间是9.18分,而标准时间是9.28分,ntpd会在一段时间内逐渐的把时间校准到与标准时间相同,而ntpdate会立刻把时间调整到9.28分,如果你往数据库内写入内容或在其他对时间有严格要求的生产环境下,产生的后果会是很严重的。(注:当本地时间与标准时间相差30分钟以上是ntpd会停止工作)
    xfs文件系统会把inode存储在磁盘最开始的这1T空间里,如果这部分空间被完全填满了,那么就会出现磁盘空间不足的错误提示了。解决办法就是在挂载时,指定 inode64 选项。
    在做网络服务器的时候,会碰到各种各样的网络问题比如说网络超时,通常一般的开发人员对于这种问题最常用的工具当然是tcpdump或者更先进的wireshark来进行抓包分析。通常这个工具能解决大部分的问题,但是比如说wireshark发现丢包,那深层次的原因就很难解释了。这不怪开发人员,要怪就怪linux网络协议栈太深。我们来看下: 这7层里面每个层都可能由于各种各样的原因,比如说缓冲区满,包非法等,把包丢掉,这样的问题就需要特殊的工具来发现了。 好了,主角dropwatch出场.
     开始程序运行的非常稳定,稳定到我想送所有说HGETALL是个坑的人一个字:呸!此时的我就像温水里的青蛙一样忘记了危险的存在,时间就这样一天一天的过去,突然有一天需求变了,我不得不把HASH数据的内容从十几个字段扩展到一百多个字段,同时使用了Pipelining一次性获取上百个HGETALL的结果。于是我掉坑里了:服务器宕机。 为什么会这样?Redis是单线程的!当它处理一个请求时其他的请求只能等着。通常请求都会很快处理完,但是当我们使用HGETALL的时候,必须遍历每个字段来获取数据,这期间消耗的CPU资源和字段数成正比,如果还用了Pipelining,无疑更是雪上加霜。
    限制带宽简直就是系统管理员的永恒话题之一。当然我这里就不讨论端口限速什么的了,百度一下一大把。但如果要的是限制某个特定进程的带宽,事情就有趣多了。
    某客户有一服务器,shared pool 相关latch出现异常等待,影响系统性能.分析结果:因为系统空闲内存太少,使用太多Paging Space导致该异常;解决办法:1.增加内存,2.在业务接受范围内减小sga等其他和内存消耗相关参数
    ​Q. 如何在目录中找出所有大文件? A. 1) 句法 for RedHat / CentOS / Fedora Linux find {/path/to/directory/} -type f -size +{size-in-kb}k -exec ls -lh {} \; | awk ‘{ print $9 “: ” $5 }’
    Travis CI,是一个专门为开源项目打造的持续集成环境。如果你有一个放在github上的开源项目,Travis CI简直就是一个完美的CI选择。下面以Moco为例,说明如何在自己的项目里添加Travis CI支持。实际上,只要采用的是“标准工具”,支持Travis CI就简单得一塌糊涂。
    写硬盘:为了持久化, 必须写硬盘。 Log 文件:为了快速写入硬盘, 必须采用追加方式顺序写到 log 文件. 这导致 log 文件中的数据是无序的。 sst 文件:为了快速从硬盘中读取数据, 基于查找算法和局部性原理考虑, 必须将数据排序组织到 sst 文件中。 多个 sst 文件而不是单个:为了快速的插入数据到 sst 文件中, 必须使用多个 sst 文件, 每个 sst 文件只保存一定范围的数据. 堆。 Levels:为了减少 log 文件合并所影响的 sst 文件个数, 将 sst 按层次组织, 层次越深, 文件数量越多. 最坏的情况, 每一次合并都会修改该层次所有的 sst 文件. 而层次越深, 合并发生的概率越小. 树。 Bloom Filter:由于 LevelDB 在某一层查找不存在的数据时, 会继续在下一层进行查找, 所以对于不存在的数据的查找会速度非常慢. 所以, 需要结合 Bloom Filter, 利用 Bloom Filter 能快速地判定”不存在”的特点.​
    起因 对 Ubuntu 频繁的版本升级有点厌倦了,6 个月的更新周期有些短。 不升级吧经不住诱惑, 升级吧往往需要花专门的时间处理,解决或大或小这样那样的问题, (最近几次好多了,出现问题很少,但还是不放心)。 Rpm 系的不喜欢,不考虑。 Debian 吧嫌它有点旧,sid 嫌不稳定。 希望尝试滚动升级的发行版,目前的选择看来看去也就是 Gentoo 和 Arch 了。 Gentoo 需要编译不考虑,Arch 看来不错,但它的追新特性让我比较担心。 我希望即使几个月或者几年不更新,也能够比较顺利的更新到最新版。 除了 Arch,看起来也没有别的更加合适的发行版了, 于是就做了很多功课,发现 Arch 也不是像瓷瓶那样脆弱, 一般只要不是以年为间隔进行升级应该不致命, 实在弄坏了就重装吧,多重装几次就当是复习了。 另外还可以琢磨一些办法快速安装软件,以及有效保存、管理自己的 配置文件 。
    Sheepdog的块设备驱动写好有一段时间了,陆续修改了几个版本之后,近期进行压测的时候遇到一个死锁的问题,头痛了一个多星期,今天请教了一下淘宝内核组的@伯瑜同学,在他的热情帮助下分析出来了死锁出现的原因,解决的办法暂未找到,或者说这问题无解,待我细细说来。
    在linux系统中,ssh是远程登录的默认工具,因为该工具的协议使用了RSA/DSA的加密算法.该工具做linux系统的远程管理是非常安全的。telnet,因为其不安全性,在linux系统中被搁置使用了。 ssh有一套很有用的工具,其中的ssh-keygen可以用来生成private和public密钥.将生成的public密钥拷贝到远程机器后,可以使ssh到另外一台机器的登陆不用密码.具体方法如下.
[ 共606篇文章 ][ 第12页/共31页 ][ |< ][ 8 ][ 9 ][ 10 ][ 11 ][ 12 ][ 13 ][ 14 ][ 15 ][ 16 ][ 17 ][ >| ]
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1