手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表Tag:yii

元旦记事

元旦其实过的很快,不上班比上班还累,这是有小孩的人都会这么想的吧?
元旦期间,手被烫伤
小孩很听话,只是偶尔问他,爸爸对你凶不凶,在想了一会之后都是很坦然的说:很凶
最近一直在尝试改变,对小孩不要那么凶,确实没有什么太大的意义。何必呢?毕竟大我时候,都是丈母娘他们在带着孩子。
元旦带小孩去买了点衣服,想着过年回家的时候可能会穿。
元旦还处理了一些旧书,40多斤的书,只折成了20多块钱,原价大约600多吧。想想也确实可惜,买不如借,借不如租,租不如偷,袁枚当初就是这样说的吧?他当然不会说租不如偷。所幸卖掉的这些书,我都看完了。否则心更痛。
整理书的时候发现原来我有那么多书没有看完过。大于等于10本书没有看全,只看了几章的也有。这时候就在迷惘我是该慢慢看完,还是确实就扔在那里?想看的时候再看?
带着孩子还去了游乐场,小孩子其实没玩多少,反而都是我和我老婆在玩。好象有点不太厚道。。。。

新的一年初始,还算是不错,唯一就是半夜小孩起来尿尿的时候,尿了一床,嗯,没对准塑料面盆,有点纠结。总体还是不错。

Tags: 2012

转:apache一个优化小技巧

determine the MaxClient

決定 web server 效能一個最重要的因素就是記憶體的量,而藉由調整 MaxClient,可以避免 Apache 產生過多無用的 child process。這個數字到底要調到多少,老實說也沒有一個標準答案,網路上大家比較建議的算法都是用機器有的記憶體和每個 child process 的 size 去做粗估。但事實上,要估計 apache child process 的 size 也不是一件容易的事,如果你用 ps aux 這個指令去看,出來的 VSZ or RSS value,其實都會把 shared memory 重覆記算(詳細內容請參考: Understanding memory usage on Linux , Memory usage determination with the ps command ),所以後來我採用的作法是:先將 MaxClent 設成一個比較小的值 (e.g. 30),然後再定期去看 error log 是否有 run out of clients 的情形,如果有的話,就再幫 MaxClients 加個 5。

原文来自:http://brooky.cc/2011/06/30/practical-guide-on-setup-wordpress-on-amazon-ec2-free-tier/

disable “AllowOverride”

 

理論上,AllowOverride 會造成 Apache 在路徑的每一層去找找看是否有 .htaccess 這個 file。
例如說:如果 virtual host 的設定是:

DocumentRoot /www/htdocs AllowOverride all

那任何一個 /index.html 的 request, Apache 都會試著去找 /.htaccess, /www/.htaccess, and /www/htdocs/.htaccess.
所以除非必要,是可以將 AllowOverride 設成 None.

但如果你用了 wordpress Pretty Permalinks”這個功能,那就會需要 rewrite rule 的功能。在這種情況下,可以考慮將 AllowOverride 的設定直接寫在 config 檔裡。

----------
上文中的链接:Memory usage determination with the ps command

The ps command can also be used to monitor memory usage of individual processes.

The ps v PID command provides the most comprehensive report on memory-related statistics for an individual process, such as:

  • Page faults
  • Size of working segment that has been touched
  • Size of working segment and code segment in memory
  • Size of text segment
  • Size of resident set
  • Percentage of real memory used by this process
The following is an example:
# ps v 
PID TTY STAT TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM COMMAND
 36626 pts/3 A 0:00 0 316 408 32768 51 60 0.0 0.0 ps v

The most important columns on the resulting ps report are described as follows:

PGIN
Number of page-ins caused by page faults. Since all I/O is classified as page faults, this is basically a measure of I/O volume.
SIZE
Virtual size (in paging space) in kilobytes of the data section of the process (displayed as SZ by other flags). This number is equal to the number of working segment pages of the process that have been touched times 4. If some working segment pages are currently paged out, this number is larger than the amount of real memory being used. SIZE includes pages in the private segment and the shared-library data segment of the process.
RSS
Real-memory (resident set) size in kilobytes of the process. This number is equal to the sum of the number of working segment and code segment pages in memory times 4. Remember that code segment pages are shared among all of the currently running instances of the program. If 26 ksh processes are running, only one copy of any given page of the ksh executable program would be in memory, but the ps command would report that code segment size as part of the RSS of each instance of the ksh program.
TSIZ
Size of text (shared-program) image. This is the size of the text section of the executable file. Pages of the text section of the executable program are only brought into memory when they are touched, that is, branched to or loaded from. This number represents only an upper bound on the amount of text that could be loaded. The TSIZ value does not reflect actual memory usage. This TSIZ value can also be seen by executing the dump -ov command against an executable program (for example, dump -ov /usr/bin/ls).
TRS
Size of the resident set (real memory) of text. This is the number of code segment pages times 4. This number exaggerates memory use for programs of which multiple instances are running. The TRS value can be higher than the TSIZ value because other pages may be included in the code segment such as the XCOFF header and the loader section.
%MEM
Calculated as the sum of the number of working segment and code segment pages in memory times 4 (that is, the RSS value), divided by the size of the real memory in use, in the machine in KB, times 100, rounded to the nearest full percentage point. This value attempts to convey the percentage of real memory being used by the process. Unfortunately, like RSS, it tends the exaggerate the cost of a process that is sharing program text with other processes. Further, the rounding to the nearest percentage point causes all of the processes in the system that have RSS values under 0.005 times real memory size to have a %MEM of 0.0.
Note: The ps command does not indicate memory consumed by shared memory segments or memory-mapped segments. Because many applications use shared memory or memory-mapped segments, the svmon command is a better tool to view the memory usage of these segments.
-----------
第二篇:http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html

这篇文章来自blogspot,一般情况下打不开,所幸我用Read it later,直接用广本模式,让他帮我打开了。HOHO,有点长,慢慢看:

This entry is for those people who have ever wondered, "Why the hell is a simple KDE text editor taking up 25 megabytes of memory?" Many people are led to believe that many Linux applications, especially KDE or Gnome programs, are "bloated" based solely upon what tools like ps report. While this may or may not be true, depending on the program, it is not generally true -- many programs are much more memory efficient than they seem.

What ps reports
The ps tool can output various pieces of information about a process, such as its process id, current running state, and resource utilization. Two of the possible outputs are VSZ and RSS, which stand for "virtual set size" and "resident set size", which are commonly used by geeks around the world to see how much memory processes are taking up.

For example, here is the output of ps aux for KEdit on my computer:


USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
dbunker 3468 0.0 2.7 25400 14452 ? S 20:19 0:00 kdeinit: kedit

According to ps, KEdit has a virtual size of about 25 megabytes and a resident size of about 14 megabytes (both numbers above are reported in kilobytes). It seems that most people like to randomly choose to accept one number or the other as representing the real memory usage of a process. I'm not going to explain the difference between VSZ and RSS right now but, needless to say, this is the wrong approach; neither number is an accurate picture of what the memory cost of running KEdit is.

Why ps is "wrong"
Depending on how you look at it, ps is not reporting the real memory usage of processes. What it is really doing is showing how much real memory each process would take up if it were the only process running. Of course, a typical Linux machine has several dozen processes running at any given time, which means that the VSZ and RSS numbers reported by ps are almost definitely "wrong". In order to understand why, it is necessary to learn how Linux handles shared libraries in programs.

Most major programs on Linux use shared libraries to facilitate certain functionality. For example, a KDE text editing program will use several KDE shared libraries (to allow for interaction with other KDE components), several X libraries (to allow it to display images and copy and pasting), and several general system libraries (to allow it to perform basic operations). Many of these shared libraries, especially commonly used ones like libc, are used by many of the programs running on a Linux system. Due to this sharing, Linux is able to use a great trick: it will load a single copy of the shared libraries into memory and use that one copy for every program that references it.

For better or worse, many tools don't care very much about this very common trick; they simply report how much memory a process uses, regardless of whether that memory is shared with other processes as well. Two programs could therefore use a large shared library and yet have its size count towards both of their memory usage totals; the library is being double-counted, which can be very misleading if you don't know what is going on.

Unfortunately, a perfect representation of process memory usage isn't easy to obtain. Not only do you need to understand how the system really works, but you need to decide how you want to deal with some hard questions. Should a shared library that is only needed for one process be counted in that process's memory usage? If a shared library is used my multiple processes, should its memory usage be evenly distributed among the different processes, or just ignored? There isn't a hard and fast rule here; you might have different answers depending on the situation you're facing. It's easy to see why ps doesn't try harder to report "correct" memory usage totals, given the ambiguity.

Seeing a process's memory map
Enough talk; let's see what the situation is with that "huge" KEdit process. To see what KEdit's memory looks like, we'll use the pmap program (with the -d flag):


Address Kbytes Mode Offset Device Mapping
08048000 40 r-x-- 0000000000000000 0fe:00000 kdeinit
08052000 4 rw--- 0000000000009000 0fe:00000 kdeinit
08053000 1164 rw--- 0000000008053000 000:00000 [ anon ]
40000000 84 r-x-- 0000000000000000 0fe:00000 ld-2.3.5.so
40015000 8 rw--- 0000000000014000 0fe:00000 ld-2.3.5.so
40017000 4 rw--- 0000000040017000 000:00000 [ anon ]
40018000 4 r-x-- 0000000000000000 0fe:00000 kedit.so
40019000 4 rw--- 0000000000000000 0fe:00000 kedit.so
40027000 252 r-x-- 0000000000000000 0fe:00000 libkparts.so.2.1.0
40066000 20 rw--- 000000000003e000 0fe:00000 libkparts.so.2.1.0
4006b000 3108 r-x-- 0000000000000000 0fe:00000 libkio.so.4.2.0
40374000 116 rw--- 0000000000309000 0fe:00000 libkio.so.4.2.0
40391000 8 rw--- 0000000040391000 000:00000 [ anon ]
40393000 2644 r-x-- 0000000000000000 0fe:00000 libkdeui.so.4.2.0
40628000 164 rw--- 0000000000295000 0fe:00000 libkdeui.so.4.2.0
40651000 4 rw--- 0000000040651000 000:00000 [ anon ]
40652000 100 r-x-- 0000000000000000 0fe:00000 libkdesu.so.4.2.0
4066b000 4 rw--- 0000000000019000 0fe:00000 libkdesu.so.4.2.0
4066c000 68 r-x-- 0000000000000000 0fe:00000 libkwalletclient.so.1.0.0
4067d000 4 rw--- 0000000000011000 0fe:00000 libkwalletclient.so.1.0.0
4067e000 4 rw--- 000000004067e000 000:00000 [ anon ]
4067f000 2148 r-x-- 0000000000000000 0fe:00000 libkdecore.so.4.2.0
40898000 64 rw--- 0000000000219000 0fe:00000 libkdecore.so.4.2.0
408a8000 8 rw--- 00000000408a8000 000:00000 [ anon ]
... (trimmed) ...
mapped: 25404K writeable/private: 2432K shared: 0K

I cut out a lot of the output; the rest is similar to what is shown. Even without the complete output, we can see some very interesting things. One important thing to note about the output is that each shared library is listed twice; once for its code segment and once for its data segment. The code segments have a mode of "r-x--", while the data is set to "rw---". The Kbytes, Mode, and Mapping columns are the only ones we will care about, as the rest are unimportant to the discussion.

If you go through the output, you will find that the lines with the largest Kbytes number are usually the code segments of the included shared libraries (the ones that start with "lib" are the shared libraries). What is great about that is that they are the ones that can be shared between processes. If you factor out all of the parts that are shared between processes, you end up with the "writeable/private" total, which is shown at the bottom of the output. This is what can be considered the incremental cost of this process, factoring out the shared libraries. Therefore, the cost to run this instance of KEdit (assuming that all of the shared libraries were already loaded) is around 2 megabytes. That is quite a different story from the 14 or 25 megabytes that ps reported.

What does it all mean?
The moral of this story is that process memory usage on Linux is a complex matter; you can't just run ps and know what is going on. This is especially true when you deal with programs that create a lot of identical children processes, like Apache. ps might report that each Apache process uses 10 megabytes of memory, when the reality might be that the marginal cost of each Apache process is 1 megabyte of memory. This information becomes critial when tuning Apache's MaxClients setting, which determines how many simultaneous requests your server can handle (although see one of my past postings for another way of increasing Apache's performance).

It also shows that it pays to stick with one desktop's software as much as possible. If you run KDE for your desktop, but mostly use Gnome applications, then you are paying a large price for a lot of redundant (but different) shared libraries. By sticking to just KDE or just Gnome apps as much as possible, you reduce your overall memory usage due to the reduced marginal memory cost of running new KDE or Gnome applications, which allows Linux to use more memory for other interesting things (like the file cache, which speeds up file accesses immensely).

Tags: apache

转perfgeeks的:记一次tps提升,做的配置变更

这次的转贴内容其实更象一个找到问题的过程,可以用来参考也可以用来思考,当你遇到问题的时候应该怎么做。
原文地址在:http://www.perfgeeks.com/?p=668
内容如下:

记一次tps提升,做的配置变更

tps低,响应时间高,并发能力差。

1.应用本身,通过xhprof找出问题代码。产生系统内核调用函数尽量避免调用。比如is_file(), time(),require/include代替require_once/include_once等。
2.尽量使用memcached缓存系统配置、模块数据、还有用户数据。减少mysqli_query()执行次数,它比较耗资源。开启mysqld的slow_query日志功能,优化那些较慢的sql查询语句。
2.通过xhprof,我们发现load和run源文件需要不少的挂钟时间,可以开启apc缓存opcode,同时设置apc.stat=off。还可以使用apc的apc_define_constants()代替php的define()
3.通过apc和memcached,收效可见,但是tps并没有提升到理想状态,同时tps不稳定,还会触底。php代码本身的优化效果甚微,对tps贡献不大。
4.重新编译php,将不必要的模块和功能禁用掉,只编译需要的。
5.配置php.ini,将不必要的模块去掉,比如gd(我们的应用不需要处理图片),soap,xhprof,mssql等。通过pmap或者lsof 可以查看一个php-cgi加载了哪些模块。减少模块加载,可以节约内存。尽量通过php.ini进行php设置,避免在代码中调用init_set操 作。比如设置时区,设置session等等。尤其data.timezone需要配置。
6.通过禁用xhprof,大概可以省下5000个cs。xhprof用完了,就应该关闭。
7.正确地设置php-fpm.max_children数量。过多的max_children浪资内存资源,还会增加cs。当然,过少的max_children会响应502。可以通过top命令观察,调整该值。
8.php-fpm使用sock方式配置。php-fpm.listen_address=/var/run/php-cgi.sock,同时nginx也需要配置fastcgi_pass指向该sock文件。
9.设置nginx.worker_processes,分别尝试了2、4、8几个值。网上大量资料说设置为cpu数*核数,其实更需要根据你的需求来设 定这个值。worker值越大,表示同时处理量大但速度更慢,相反表示处理速度能力强但数量更小。如果做为反向代理服务器,worker值可以大一点,如 果做为web逻辑服务器,值可以小一点。
10.网络IO,选择支持多路复用模型epoll,FreeBSD采用kqueue。如果网站流量小,选择select也还是不错的。
11.开启持久连接机制keep-alive,keep-alive可以复用tcp/ip连接,大量地减少了accept()系统内核调用。这里将nginx.keepalive_timeout设置为60.注意http/1.1默认开启keep-alive
12.gzip,压缩http响应输出。当响应输出量足够小,使用gzip压缩并没有意义。可以通过gzip_min_length指定跳过gzip压缩。
13.关闭nginx.access_log。通过access_log off可以不记录日志。减少不必要的磁盘I/O操作。如果开启日志功能,最好写个脚本将日志按量分割成更小的文件。
14.对于静态资源服务器,可以开启sendfile功能和设置expires缓存新鲜期。
15.将selinux设置为disabled,命令setenforce 0,只是将selinux设置为permissive,该模式会执行安全策略检查并打印警告。
16.通过chkconfig管理系统随机开启的守护进程。将不必要启动的守护进程关闭,比如sendmail, portmap, atd, netfs, nfslock等。这些守护进程浪费内存空间。
17.关闭防火墙,iptables –flush可以清除所有防火墙规则。
18.将不必要的进程关闭。比如/sbin/mingetty只需要开启3个就足够用,可以在/etc/inittab配置。比如gdm进程,通过 /etc/inittab将id:5:initdefault:改为id:3:initdefault:。等等。通过ps -ef可以查看你当前打开的进程,请确定每一个进程都”出师有名”。
19.资源限制,每个进程可以打开的文件最大数量默认是1024,通过ulimit设置更大的值(ulimit -SHn 65535)。如果没有生效,可以编辑资源限制配置文件/etc/security/limits.conf。同时别忘记了将php- fpm.rlimit_files和nginx的worker_rlimit_nofile、worker_connections设置同样大小。
20.优化磁盘IO,添加挂载参数noatime。可以编辑/etc/fstab,注意不要在/etc/fstab增加挂载参数data=writeback,会导致磁盘挂载为ro。
21.关闭ipv6内核模块
22.增加dns查询记录至/etc/hosts。比如222.73.211.215 www.perfgeeks.com
23.调整内核参数。经过一番折腾,tps有提升,但是不稳定,通过sysctl调整内核参数则稳定了。
net.ipv4.tcp_max_syn_backlog = 65536
net.core.netdev_max_backlog = 32768
net.core.somaxconn = 32768

net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

net.ipv4.tcp_tw_recycle = 1
#net.ipv4.tcp_tw_len = 1
net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_max_orphans = 3276800

#net.ipv4.tcp_fin_timeout = 30
#net.ipv4.tcp_keepalive_time = 120
net.ipv4.ip_local_port_range = 1024 65535

通过一番辛苦,tps终于从120升到了810,并且tps曲线平衡(几乎时条直线),cpu资源的利用率也很平衡80%的us和20%的sys。 要提高tps,首先要保证单个请求响应时间不能过长。响应时间过大,tps较难提升。更少的上下文切换和更少的系统内核调用,更少的IO操作可以换得更大 的tps。通过strace可以统计出调用了哪些系统内核调用,帮助你优化应用。减少上下文切换最有效的办法就是减少进程数量。

Tags: php, xhprof, tps

PhpStorm 3.0 released!

一大早就收到这封邮件,灰常开心。
因为在2.x的时候用的就是它,而且,除了代码格式化外(数组这一块的格式化非常不友好),其它我都非常满意。当然也可能是我没有把netbeans的所有能力都发挥出来吧,先看邮件:
PhpStorm 3.0 is now available and introduces the Smart Duplicated Code Detector to help you quickly find similar blocks through your entire code base and securely get rid of them without losing the intended functionality.
Also a new integrated UML tool allows you to quickly get a bird’s-eye-view of your project structure, or even a semantic view of the changes in the recent VCS commits made by your colleagues.
Furthermore, to ensure that your code works fast and doesn’t cause any performance bottlenecks, the IDE now includes a profiler, a new PHPUnit test runner and JSTestDriver.

The new key functionality in PhpStorm 3.0 includes:
- Smart Duplicated Code Detector
- PHP UML roundtrip diagrams
- Profiling results browser for Xdebug and Zend Debugger engines
- PhpUnit 3.6 integration
- CoffeeScript support
- Significant improvements to FTP/SFTP Sync
- TFS support and revision graph for GIT
- Streamlined UI across all operating systems

HOHO,看到没,居然PHP UML roundtrip diagrams,但其实在EAP版的时候,我试过,其实并没有想象中的那么完善,将就着能用用而且。 ftp/sftp 同步还没有试过。。什么时候试用下

Tags: phpstorm, release

来自dbanotes:对 Pinterest 类应用的一点思考

这是冯大辉的博客中的一篇文章,看看之余我也在剖析自己的内心。我是该继续做开发,还是转行做产品?
虽然我对产品的理解和设计暂时还不如那些专业的产品经理,但是从事互联网这么多年,没见过猪跑总还吃过猪肉的吧?
OK,先上原文,再继续乱弹,原文来自: 对 Pinterest 类应用的一点思考

最近一段时间 Pinterest 类应用相当火爆,引发了不少讨论。我自己最近也一直在使用花瓣 ,也在捉摸为什么这一类应用这么有魔力。知乎上有个问题是: Pinterest 好在哪里?,尝试做了一下回答,也稍作整理,发在这里做个记录,会随着理解再做进一步修改。

本质上,Pinterest 类应用属于社会化书签站点的延续,只是要处理的数据对象变成了「图片」,而不是传统社会化书签的URL。这是社会化信息处理的一次改良。

提到社会化书签,不得不提 Del.icio.us ,不过或许 Del.icio.us 模式已经到头了,即使现在从Yahoo! 手里卖给了陈士骏,也不太可能玩出新花样,因为核心的数据对象没变。

相比 Flickr 来说,Pinterest 主要的生成内容动作是 Pin (花瓣叫采集),而 Flickr 则是 Upload,这个动作上的不同导致 Flickr 向左,Pinterest向右。Flickr 重心是「照片」(Picture),尤其是原创照片,而非图片(Image)。 Flickr的一个弊端是大量的图片没有标题,这意味着元数据的先天不足,不太可能和其他网络内容进一步结合起来。但是也要说一下,Flickr 现在的价值是被低估了。

Pinterest 相对 Flickr 来说,恰恰是一种互补,每张图片基本可以关联到一条URL,进一步可以抽取其他信息。

从用户行为的角度上看,满足了用户天生的「收集癖」,很多人都有看到一张照片想顺手存起来的冲动,没有Pinterest这类产品之前,这个交互操作太费事了... Pinterest 无疑弥补了人的这个原始的需求。

Pinterest 类应用的创新之处我认为是「降低了收集信息的门槛」,或者,至少做到了这一点。其价值是不言而喻的,每一次信息处理的门槛降低都会得到商业价值的变现,你可以不信。

要有足够好的技术团队支撑、足够好的数据处理能力才能走到最后,这也是在国内众多产品中我看好花瓣(huaban.com)的主要理由。

--EOF--

目前现在很多网站都在做Pinterest正在做的事情,而且由于国内广大网民(非设计师、程序员、产品)接触国外网站的机会比较少,因此,这些有创意的复刻版在国内就变得很流行了。

说到美味书签,真要算的话,国内其实也有很多做类似的,只是很多人都不习惯它的使用方法。但要说他死了?也不见得,毕竟书签有很多展示方式,比如:read it later,难道就不能算是一个书签?它也能够通过API的方式来对外分享,而且正因为提供了API,使得在任意平台上都可以支持了read it later,越往后,书签就越来越趋向于移动设备的支持,但移动设备的屏幕小,不适合看书签收藏的网页中提供的内容。所以read it later提供的纯文本阅读,就使得这个缺陷被无限缩小了。

象Pinterest这类网站,还真的不好说能够在移动设备上占优势,流量啊,那可是要钱的东西,you know.

Tags: dbanotes, fenng