<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Dev Problem &#8211; HU Xiaoxu</title>
	<atom:link href="https://blog.ihuxu.com/category/computer-science/dev-problem/feed/" rel="self" type="application/rss+xml" />
	<link>https://blog.ihuxu.com</link>
	<description>a software engineer&#039;s blog</description>
	<lastBuildDate>Wed, 18 Jun 2025 15:29:31 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.6.2</generator>
	<item>
		<title>小型网站架构降 Apache 与 MySQL 内存占用比率</title>
		<link>https://blog.ihuxu.com/how-to-configure-the-apache-and-mysql-server-effectively-under-the-framework-of-a-small-web-site/</link>
					<comments>https://blog.ihuxu.com/how-to-configure-the-apache-and-mysql-server-effectively-under-the-framework-of-a-small-web-site/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Tue, 13 Dec 2016 11:38:12 +0000</pubDate>
				<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[Dev Problem]]></category>
		<category><![CDATA[Apache]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Memory]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[Original]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=9365</guid>

					<description><![CDATA[前言 这篇文章以我的阿里云服务器为例（你眼前的博客正是搭在这个服务器上），阐述下小型网站（Linux+Apache+MySQL+PHP）对于内存利用率提升的配置方法的一个点。 正文 我的服务器是阿里云的，在一年前由于数据库（MySQL）频繁内存不足宕机就“潇洒”地升级了配置到2G内存。所以，目前机器的配置如下： CPU： 1核 内存： 2048 MB 操作系统： CentOS 6.5 32位 公网IP： 115.28.36.19 带宽计费方式： 按固定带宽 当前使用带宽： 1Mbps 同时，正常使用情况下的内存使用情况如下： 图中显示 MySQL 占用 440m，Apache 占用 44m。当然，这是MySQL 服务和 Apache 服务刚刚重启后的情况。实际的内存占用会比这大，因为随着业务的进行，会进行 Cache 的累积，最后导致整体的使用内存增大。 下面分别调整 MySQL 和 Apache 的配置文件。 MySQL 修改 /etc/my.cnf 文件，增加如下配置内容： 内容使用情况如下： 如图所示，在修改 MySQL 配置项后内存使用已经大幅度下降到 71m 了。所以，默认的 MySQL 配置真是不适合我们这种小型网站。同时，你会注意到运行了一段时间后，Apache 内存占比上升，使用量达到406m。真是可怕。 下面我们修改 Apache 的配置文件，httpd.conf： 由于我的 Apache 加载的是 event 模式，所以我这里修改了相应的 event 模块配置。如果你想知道你自己加载的是哪种模式，每一个配置项是什么意思，那么你可以参阅下这篇文章：apache2.4.x 三种 MPM 介绍。 修改后配置重启就 OK 了。 总结 没有总结]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/how-to-configure-the-apache-and-mysql-server-effectively-under-the-framework-of-a-small-web-site/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>在 Linux 下通过 strace 与 lsof 命令排查 PHP 异常进程</title>
		<link>https://blog.ihuxu.com/php-abnormal-process-investigation/</link>
					<comments>https://blog.ihuxu.com/php-abnormal-process-investigation/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Wed, 30 Nov 2016 03:02:51 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[Dev Problem]]></category>
		<category><![CDATA[Foundation]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Operation System]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Original]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=9350</guid>

					<description><![CDATA[在有些时候，会遇到 PHP 进程异常卡死的情况。面对这种情况，首先考虑到的就是分析代码进行优化改进，或者重启进程。但是，这种方式来排查不一定能找到根本原因。因为有些时候异常 PHP 进程卡死的原因可能是非常奇葩的问题，比如外部资源异常如 DB、Redis 或第三方 API 等。上一次关于超级话题签到提醒定时任务 PHP 进程异常的处理，问题竟然出现在外部的 DB 的链接上。由于网络原因导致读取 DB 没有响应卡死。 这一次情况比较严重，超级话题积分系统的计算有一部分是通过 Trigger（类似队列）接受全站数据进行积分计算与入库。由于用户反馈问题，来到队列机查看进程情况。如下： 之后，我们查看某个进程的处理日志。如下： 发现进程（pid 10693）在重启之后卡主。 于是利用 strace 查看进程处理过程： 如 strace 信息可以看出，该异常 PHP 进程一直在循环的读取，貌似进入死循环： 接着利用 lsof 来查看该进程的所有链接资源，如下： 所以，可以看出该 PHP 异常进程是在不断的读取 FD 值为 4u 对应的资源，该资源正式 trigger 的服务资源。 通过上述的判断，可以初步断定出现在 trigger 服务上，接着就是找相关部门的人继续深入排查了。 注：已处理敏感信息，如有问题请及时联系站长。]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/php-abnormal-process-investigation/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>基于 libgit2 C 语言库的 php-git 扩展 fix bug 辛酸史</title>
		<link>https://blog.ihuxu.com/the-experience-of-the-fixing-libgit2-git-diff-tree-to-tree-bug/</link>
					<comments>https://blog.ihuxu.com/the-experience-of-the-fixing-libgit2-git-diff-tree-to-tree-bug/#comments</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Sat, 27 Aug 2016 09:41:31 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[Dev Problem]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[C]]></category>
		<category><![CDATA[Original]]></category>
		<category><![CDATA[PHP Extension]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=1181</guid>

					<description><![CDATA[前言 这是一篇极其没有节（nei）操（rong）的文章。除非你真的无聊，请不要阅读，否则后果自负~ 正文 最近，在忙活微博话题组的日构建工具。工具主要的功能并不算复杂。写着写着，外面雨过天晴，居然还放起爆竹了，什么鬼。 构建工具的主要功能正如介绍中所述的那样，提取产品、测试等基本信息、提取版本库（git）信息、检查（编译）源文件、自动部署项目与发送邮件等。在提取 git 库信息时，相对于之前利用 shell_exec PHP 原生函数提取 svn 信息的方式，打算利用扩展来提取信息。一来更规范、更有效率（微乎其微），二来专业。缺点是相对而言部署环境麻烦，因为需要安装 git 扩展到当前 php 运行环境中来。 但是，万万没想到官方推荐的 php-git 扩展库开发版本已有3年没有维护了。索性用吧，又能怎样。 安装 还算顺利，由于公司开发机没有 cmake，yum 源也不可用，懒得配置，直接 download 一套源码。 上述步骤自行领会，注意上述适用于 64 位 Linux 系统，32 位的 Linux 请见上述提到的 php-git 库说明文档。 使用 我们提取的 git 信息基本也就是从上一次部署版本，到该次部署版本之间的 log 和 diff 信息。所以，第一件事情，就是拿到这段的 commit hash 值。关于下文中提到的 commit hash 和 tree hash 概念可以自行 google 或参见博客libgit2使用教程（特别篇）几个基本概念说明。 在拿到 commit hash 之后，将通过 git_diff_tree_to_tree 方法拿到每个 commit hash 之间的 diff 信息。通过方法名可以知道，这个 diff 信息是通过两个 tree 拿到的。 调用代码：<div class="read-more"><a class="btn read-more-btn" href="https://blog.ihuxu.com/the-experience-of-the-fixing-libgit2-git-diff-tree-to-tree-bug/">Read More</a></div>]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/the-experience-of-the-fixing-libgit2-git-diff-tree-to-tree-bug/feed/</wfw:commentRss>
			<slash:comments>2</slash:comments>
		
		
			</item>
		<item>
		<title>微信支付 JSAPI 开发中的问题</title>
		<link>https://blog.ihuxu.com/wechat-pay-sdk-development/</link>
					<comments>https://blog.ihuxu.com/wechat-pay-sdk-development/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Sun, 23 Nov 2014 15:15:13 +0000</pubDate>
				<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[Dev Problem]]></category>
		<category><![CDATA[Original]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[SDK]]></category>
		<category><![CDATA[WeChat]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=89</guid>

					<description><![CDATA[前言：这篇文章讲的是利用微信官方提供的 JSAPI 接口，实现微信网页支付。希望在看之前，要确认以下几件事情，否则会在解决问题时很费解。 ①　接口文档版本号是 V3.3（在官方提供的 PHP DEMO 中的 README.txt 文件中查看。当然，也可以参考压缩包的名字（wxm-payment-biz-api218f8e.zip）来确认版本 ②　微信支付 PDF 文档的版本为 V3.3.7（如果上述版本对了，这步应该也是一致的，因为这两个文件是在一个包里） ③　该文章说的是 JSAPI 的开发 简单看了下微信支付的文档和源码（压缩包名：wxm-payment-biz-api218f8e.zip；PDF 文档名：【微信支付】微信公众号支付接口文档V3.3.7.pdf；）。然后，修改了微信的配置文件。有如下几个配置项值得注意： 1、 MCHID 注释是“受理商 ID，身份标识”。可以在邮件中查看，这个邮件是在申请支付的某个流程中回执的。由于我不是微信号的“主人”，所以具体在哪个环节不好确定。同时，邮件中还会有个密码。利用这个 MCHID 和密码可以到微信商户平台（https://pay.weixin.qq.com/）登录，进入管理商户订单的界面。 2、 KEY&#160; 这个 KEY 有些苦逼啊，文档注释说是“商户支付密钥 Key。审核通过后，在微信发送的邮件中查看”。但并没有在邮件里找到这个 KEY ！算了，百度了下，发现是在微信商户平台设置的。利用上面提到的账户信息登录商户平台后，点击左侧的“安全设置”（记不清了，如果不是这个关键字，找到证书管理的选项即可），然后需要安装浏览器证书插件后，手动设置这个 KEY。随意设置，可以用 MD5 加密后的字符串，比如 MD5(&#8220;Foo&#8221;)。 3、 SSLCERT_PATH 注释为“证书路径，注意应该填写绝对路径”，给的默认格式为“/xxx/xxx/xxx/WxPayPubHelper/cacert/apiclient_cert.pem”。但是，我直接用的“http://www.domain.com/wxpay/cacert/apiclient_cert.pem”这种格式。因为，简单看了下利用这个常量的调用代码，用的是 Curl 函数，那么我想用 http 开头的链接应该不会有问题了。 4、 SSLKEY_PATH 同上 5、 CURL_TIMEOUT&#160; 这个常量在这个版本的 DEMO 中没有用到，直接写的 30，开发者注意修改。 刚才介绍了几个有歧义的常量，下面还有个问题需要注意。在 WxPayPubHelper.php 文件中的第155行的常量有拼写错误。 官方的文档我很无语哦！&#160;：《 好了，配置项 OK 了。程序部署到网站的 wxpay 项目下(http://www.domain.com/wxpay/)。然后在微信公众号管理后台的微信支付的界面中进行了支付授权目录的设置。设置后不知道为什么显示为空，我没有注意。同时，我在支付测试目录中也设置了路径，同时把测试号的微信 ID 填入白名单。 这时，测试的时候一直提示 system:access_denied（同：system:not_allowed）。 接着，仔细看了下 PDF 文档，觉得问题出现在支付授权目录下，果不其然。切记，阅读官方文档是多么的重要！ 解决步骤：把测试账号的微信 ID<div class="read-more"><a class="btn read-more-btn" href="https://blog.ihuxu.com/wechat-pay-sdk-development/">Read More</a></div>]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/wechat-pay-sdk-development/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
