记录:恢复windows更新后,grub rescue> error unknow filesystem错误

在grub resuce模式中,通过ls确认自己的所有分区。

找到自己的root和boot分区.

如果你的root分区是(hd0,gpt7)

set root=(hd0,gpt7)\

如果你的boot分区是(hd0,gpt6)


set prefix=(hd0,gpt6)\grub

(如果没有将boot和root区分开,则为实际目录.

然后正常进入grub菜单

insmod normal

normal

正常启动linux后,以root权限执行

update-grub 

grub-install /dev/sda


完成收工


参考:https://askubuntu.com/questions/142300/how-to-fix-error-unknown-filesystem-grub-rescue

发布于
2018-01-12

记录:golang中错误在for range中对值使用了指针。

某段程序出错,最后定位到错误在大概这样的结构

    for _, v := range data {
        c <- &v
    }


这样,整个cannel里,都只有最后一个v值

整理了下思路,也很好理解。

这样的代码某种角度相当于

{
var v int
    for _, v = range data {
        c <- &v
    }
}   


而非

    for _, v = range data {
        var v int
        c <- &v
    }   


那自然都是最后一个值了。

作为一个每个循环中都要使用的值,自然不可能不停的创建新的。这太不环保。

但直接的写法里比较难直接看出来。

记录下,以后至少记得解决的方向

发布于
2018-01-08

记录:通过golang的reflect包创建value的指针

这个问题困扰了我一定时间,搜了一圈后发先自己2了

先用New创建空指针

然后给指针的Elem设置为具体的值。

主要一直以为New出来的对象没发用,是个zero value,到处panic,没反映过来elem还是可以用来set的。

其实想想也是,如果没法赋值的话,这个New函数有什么用……

大概代码:

    var v = mapvalue.MapIndex(reflect.ValueOf(key))
    var vp = reflect.New(v.Type())
    vp.Elem().Set(v)
发布于
2018-01-03

最近沉迷于神界原罪

黑5的时候发现最近很火的神接2原罪2的上一代有了官中,赶紧乘打折买了。

发现自己还是喜欢这一口老式游戏啊。

为了熟悉系统,不停的重新build重开任务,几十个小时了第一章还是没过,也是服了自己了。

最后完的还是变态了,每个队友一人学一点土系,蜘蛛,游,落石,本职技能都不高兴放,先构筑个火烟带。

把视线屏蔽了,逼迫对方移动进来,然后一群蜘蛛堵路,出头一个秒一个。

一下子体会了赤壁是面对曹军的周都督的感受啊。

自己都觉得自己太不人道了……


好久没过这么投入的体验了。上个一个能让我长时间放下dota2不玩的应该是文明5/6?

现在开始期待2出官中。

结果写这篇文字的时候,去看2有没有官中,顺手又入了个Pyre……

发布于
2018-01-02

2017年终总结

一眨眼,又到年底最后一个工作日了。

这一年过得怎么样呢?

这一年过的真不怎么样。

收入也没什么提升。

工作上用的代码,基本没什么更新,更多的时间建花在了团队构建上了。

一年过去了,自己的代码包还没完全定型。几个早早就确定要做的功能还停留在构想阶段。

不知道是不是娃越发的皮了,感觉有时候还是有点累了。

应该算是正式到了中年危机吧。

今年和去年相比,连steam上的游戏都没精心多少。照片也少拍少修了不少。

除了娃的成长。

不尽如人意啊。


发布于
2017-12-29

手机又被娃摔了

继6月份买的mix,10月份买的米6,之后,昨天又狠狠的把米6的后背摔的粉碎了。

好吧,继续换手机。换了mix2。

半年里话了9000块买小米手机,真心不容易啊……

再摔,小米也没其他机型了,估计要换华为的了……

发布于
2017-12-28

进一步优化缓存组建

脑子里还是满脑子的程序优化。

回家可能是吃饱了,灵感一动,想到了新的提升页面效率的方法。

Golang的话,本身常驻内存,不和php似的要把缓存都放在进程外,也不向nodejs是那样对多核支持不佳。

程序内存就是效率最高的缓存了。

提高效率可以先从降低redis的使用率开始。

用redis而不是内存缓存其实最主要还是为了能够分布式,或者说是冗余。

那么其实redis只要负责缓存的状态就行了,实际较大的内容,比如页面,还是缓存在本地就好了

redis里放个内容的更新状态(摘要或者甚至是时间戳都行)

赶紧着手,就着我的redis缓存和cachegroup缓存改了一个hash缓存驱动出来。

测试跑通,感觉上手。

的确有一定的提升。

从10k左右到了13k不到。

效果还算暂时能让我满意。

发现目前影响缓存效率最主要的还是内容大小。

也就是,以profile来说,目前最大的大头是 分配内存以及传递数据了。

再下去怎么优化,暂时有点失去方向了。

发布于
2017-12-16

记录:通过nginx设置为站点资源,根据国内国外使用不同的cdn

目标:加速客户网站访问,使用cdn。

为了效果以及费用考虑,国内的加载阿里云的,国外的加载cloudflare。使用nginx的变量功能实现了这一效果

首先,确认nginx有geoip模块,并下载相应geoip数据

其次,调整nginx.conf的http部分

   geoip_country /GeoIP.dat;
   geoip_city    /GeoLiteCity.dat;
   map $geoip_country_code $cdn {
       default cf;
       CN ali;
   }
然后,调整nginx反代配置,以wordpress为例

       location / {
                       set $cdnpath cfcdn.cfcdn.com;
                     sub_filter_once off;
                       if ($cdn = ali){
                               set $cdnpath alicdn.alicdn.com;
                       }
                       add_header X-Cdn $cdn; 


                       sub_filter '${host}/wp-content/' '$cdnpath/wp-content/';
                       sub_filter '${host}/wp-includes/' '$cdnpath/wp-includes/';
                       sub_filter 'http:\/\/${host}\/wp-content\/' 'http:\/\/${cdnpath}\/wp-content\/';
                       sub_filter 'http:\/\/${host}\/wp-includes' 'http:\/\/${cdnpath}\/wp-includes';
                       sub_filter 'url("/wp-content/' 'url("http://${cdnpath}/wp-content/';
                       sub_filter 'src="/wp-content/' 'src="http://${cdnpath}/wp-content/';
                       sub_filter 'src="/wp-include/' 'src="http://${cdnpath}/wp-include/';
                       proxy_pass         http://127.0.0.1:8080;
                       proxy_set_header   Host $host;
                       proxy_set_header   X-Real-IP  $remote_addr;
                       proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                       proxy_set_header   X-Scheme $scheme;
       }


完成。


发布于
2017-12-15

优化完成,发现自己自High起来越发不要脸了

终于把blog代码走redis缓存在本机提升到10k rps以上了。

手法相当无耻。

在各种分析代码后,发现cpu主要耗费在redis连接和反序列化这两个和内容长度直接相关的部分后。

直接写了个简单的gzip中间件挂在了缓存后面,缓存压缩过的数据。

一下子就ok了。


顺便,在把模板系统也折腾过一遍以后,结论:

  1. 模板系统也和输出的内容多少直接相关。
  2. blog这种长度主要在数据的,还是直接缓存页面比缓存数据+渲染快很多。
  3. Golang的template模块是真心慢。Jet html相对好不少,但还是很难让人满意。同样的首页用本地内存缓存过的数据渲染的话,大概也只有5k-6k rps。走redis就真心没法看了,2k rps出头。
  4. 在c10k这个层面,走redis的成本其实也是很高的。
发布于
2017-12-14

博客pprof分析

给blog程序做了个pprof分析。

先是安装  工具库

go get github.com/pkg/profile

然后再引入

import "github.com/pkg/profile"

再在入口中加入代码

defer profile.Start(profile.CPUProfile).Stop()

然后go build,ab跑需要的值。

再go proff ./app pprfo文件位置,输入web指令,看到全图,能按时间占用来分析网站的问题点在哪了。


就我这次分析,一共是151s/238s。

其中

http请求头解析 13s

http相应写入 26.8s

属于硬消耗,除非不使用net/http,否则基本无法避免和优化。

fd操作:

accept fd_unix 6.07s

destory fd_unix 9.76应该也是避不过。

msgpack的反序列化是27s,比我一直预期的其实要更好。

然后大头就是redis连接使用的70s了。

直接就占了总cpu消耗的1/3了。

看来只要用了 redis库,这个数量级就逃不掉了。

唯一能优化的地方是,为了能按分类优化,我加如了一个临时前缀。

这部分走的也是redis,占用了大概占用了一般的redis消耗,这是个很大的问题。


发布于
2017-12-13