• news
  • pics
  • linux
  • windows
  • proxmox
  • game
  • news
  • pics
  • linux
  • windows
  • proxmox
  • game

mysql内存超出 mysqld: Out of memory 解决办法

April 22nd, 2021

自己配置的XWAMP环境,默认下没有详细配置mysql的my.ini,一方面不同服务器的配置不一样,另一方面按照默认为空的方式也一直没有出现过问题。不过最近服务器挂掉了,出现的症状是:

网站不能打开,动态的。静态的可以。
不能远程桌面。

强制重启服务器后查看系统日志发现了这个错误:

mysqld: Out of memory (Needed 129040 bytes)

于是找到了mariadb根目录中有几个推荐配置文件:

my-small.ini:内存小于64M。

my-medium.ini:内存在32M – 64M之间。

my-large.ini:内存为512M。

my-huge.ini:内存在1G-2G之间

my-innodb-heavy-4G.ini:内存4GB,仅使用innodb存储引擎。

挂掉的服务器是2核(CPU)2GB(内存),选择了my-large.ini的推荐配置,增加了如下配置(放在[mysqld]下):

skip-external-locking
key_buffer_size = 256M
max_allowed_packet = 1M
table_open_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
thread_concurrency = 4

如何添加swap分区

April 22nd, 2021

mysqld: Out of memory (Needed 128917504 bytes)mysql安装后,启动不起来

1、查看报错

tail -n 100 /var/log/mariadb/mariadb.log

2、在使用 free -m 查看内存信息时,发现 swap 分区大小为 0。难怪说数据库服务器无法启动呢,在内存不够用的情况下,又无法使用 swap 分区,自然崩溃了

3、使用下面的命令创建 swapfile,自己创建交换分区:
第一步:创建一个大小为1000M的文件:
count=1 bs=1440k (即块大小为1.44M)
bs=1024 (指定块大小为1k)
确定硬盘的最佳块大小,自己选:
bs=1024 count=1000000
bs=2048 count=500000
bs=4096 count=250000
bs=8192 count=125000

dd if=/dev/zero of=/swapfile bs=1024 count=1048576

使用下面的命令配置 swap 文件:

mkswap /swapfile

接下来,使用下面的命令立即启用 swapfile,这样就不用等到下次重启时自动启用:

swapon /swapfile

最后,我们在 /etc/fstab 中添加下面一行,这样可以在系统下次重启时自动生效创建的 swapfile:

vi /etc/fstab

/swapfile swap swap defaults 0 0

使用 cat /proc/swaps 或 free -m 查看 swapfile 的生效情况,如下图所示:

cat /proc/swaps
free -m

proxmox去除登录订阅提示

March 29th, 2021

修改文件/usr/share/pve-manager/js/pvemanagerlib.js,大概37959行

486-2.png
Proxmox.Utils.checked_command(function() {}); // display subscription status
改成
 //Proxmox.Utils.checked_command(function() {}); // display subscription status

修改完后systemctl restart pveproxy

注销重新登录

PVE添加cpu温度显示

March 29th, 2021

一、安装lm-sensors

apt-get install lm-sensors


安装成功后,可以通过命令查看cpu温度:

[email protected]:~# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +27.8°C  (crit = +74.0°C)
temp2:        +29.8°C  (crit = +74.0°C)
 
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +38.0°C  (high = +68.0°C, crit = +73.0°C)
Core 0:        +36.0°C  (high = +68.0°C, crit = +73.0°C)
Core 1:        +35.0°C  (high = +68.0°C, crit = +73.0°C)
Core 2:        +34.0°C  (high = +68.0°C, crit = +73.0°C)
Core 3:        +38.0°C  (high = +68.0°C, crit = +73.0°C)

星际蜗牛的暴力风扇虽然吵,但是不得不佩服散热能力确实强。

二、编辑修改文件
1、/usr/share/perl5/PVE/API2/Nodes.pm

搜索my $dinfo = df(‘/’, 1);
以pve5.4.3为例,在296行:

    293         $res->{pveversion} = PVE::pvecfg::package() . "/" .
    294             PVE::pvecfg::version_text();
    295 
    296         my $dinfo = df('/', 1);     # output is bytes
    297 


添加:$res->{thermalstate} = `sensors`;
修改后:
 

        $res->{pveversion} = PVE::pvecfg::package() . "/" .
            PVE::pvecfg::version_text();
 
        $res->{thermalstate} = `sensors`;
 
        my $dinfo = df('/', 1);     # output is bytes


2、/usr/share/pve-manager/js/pvemanagerlib.js

2.1、搜索PVE.panel.StatusView,修改height为320

  16876 Ext.define('PVE.node.StatusView', {
  16877     extend: 'PVE.panel.StatusView',
  16878     alias: 'widget.pveNodeStatus',
  16879 
  16880     height: 300,
  16881     bodyPadding: '20 15 20 15',
  16882 
  16883     layout: {
  16884         type: 'table',
  16885         columns: 2,
  16886         tableAttrs: {
  16887             style: {
  16888                 width: '100%'
  16889             }
  16890         }
  16891     },


2.2、搜索PVE Manager Version

  16990         {
  16991             itemId: 'version',
  16992             colspan: 2,
  16993             printBar: false,
  16994             title: gettext('PVE Manager Version'),
  16995             textField: 'pveversion',
  16996             value: ''
  16997         }


在后面添加一个item,修改后为
 

        {
            itemId: 'version',
            colspan: 2,
            printBar: false,
            title: gettext('PVE Manager Version'),
            textField: 'pveversion',
            value: ''
        },
        {
            itemId: 'thermal',
            colspan: 2,
            printBar: false,
            title: gettext('CPU温度'),
            textField: 'thermalstate',
            renderer:function(value){
                const c0 = value.match(/Core 0.*?\+([\d\.]+)Â/)[1];
                const c1 = value.match(/Core 1.*?\+([\d\.]+)Â/)[1];
                const c2 = value.match(/Core 2.*?\+([\d\.]+)Â/)[1];
                const c3 = value.match(/Core 8.*?\+([\d\.]+)Â/)[1];
                return `核0: ${c0} ℃ | 核1: ${c1} ℃ | 核2: ${c2} ℃ | 核3: ${c3} ℃`
            }
        }


三、重启pve web管理服务

systemctl restart pveproxy


至此,就已经成功添加了pve web管理端cpu温度显示。

如何加速Linux下的编译速度(加速make)

March 26th, 2021

项目越来越大,每次需要重新编译整个项目都是一件很浪费时间的事情。Research了一下,找到以下可以帮助提高速度的方法,总结一下。

  • tmpfs

有人说在Windows下用了RAMDisk把一个项目编译时间从4.5小时减少到了5分钟,也许这个数字是有点夸张了,不过粗想想,把文件放到内存上做编译应该是比在磁盘上快多了吧,尤其如果编译器需要生成很多临时文件的话。

这个做法的实现成本最低,在Linux中,直接mount一个tmpfs就可以了。而且对所编译的工程没有任何要求,也不用改动编译环境。

mount -t tmpfs tmpfs ~/build -o size=1G

用2.6.32.2的Linux Kernel来测试一下编译速度:

用物理磁盘:40分16秒

用tmpfs:39分56秒

呃……没什么变化。看来编译慢很大程度上瓶颈并不在IO上面。但对于一个实际项目来说,编译过程中可能还会有打包等IO密集的操作,所以只要可能,用tmpfs是有益无害的。当然对于大项目来说,你需要有足够的内存才能负担得起这个tmpfs的开销。

  • make -j

既然IO不是瓶颈,那CPU就应该是一个影响编译速度的重要因素了。

用make -j带一个参数,可以把项目在进行并行编译,比如在一台双核的机器上,完全可以用make -j4,让make最多允许4个编译命令同时执行,这样可以更有效的利用CPU资源。

还是用Kernel来测试:

用make: 40分16秒

用make -j4:23分16秒

用make -j8:22分59秒

由此看来,在多核CPU上,适当的进行并行编译还是可以明显提高编译速度的。但并行的任务不宜太多,一般是以CPU的核心数目的两倍为宜。

不过这个方案不是完全没有cost的,如果项目的Makefile不规范,没有正确的设置好依赖关系,并行编译的结果就是编译不能正常进行。如果依赖关系设置过于保守,则可能本身编译的可并行度就下降了,也不能取得最佳的效果。

  • ccache

ccache用于把编译的中间结果进行缓存,以便在再次编译的时候可以节省时间。这对于玩Kernel来说实在是再好不过了,因为经常需要修改一些Kernel的代码,然后再重新编译,而这两次编译大部分东西可能都没有发生变化。对于平时开发项目来说,也是一样。为什么不是直接用make所支持的增量编译呢?还是因为现实中,因为Makefile的不规范,很可能这种“聪明”的方案根本不能正常工作,只有每次make clean再make才行。

安装完ccache后,可以在/usr/local/bin下建立gcc,g++,c++,cc的symbolic link,链到/usr/bin/ccache上。总之确认系统在调用gcc等命令时会调用到ccache就可以了(通常情况下/usr/local/bin会在PATH中排在/usr/bin前面)。

继续测试:

用ccache的第一次编译(make -j4):23分38秒

用ccache的第二次编译(make -j4):8分48秒

用ccache的第三次编译(修改若干配置,make -j4):23分48秒

看来修改配置(我改了CPU类型…)对ccache的影响是很大的,因为基本头文件发生变化后,就导致所有缓存数据都无效了,必须重头来做。但如果只是修改一些.c文件的代码,ccache的效果还是相当明显的。而且使用ccache对项目没有特别的依赖,布署成本很低,这在日常工作中很实用。

可以用ccache -s来查看cache的使用和命中情况:

cache directory                   /home/lifanxi/.ccachecache hit                           7165cache miss                         14283called for link                       71not a C/C++ file                     120no input file                       3045files in cache                     28566cache size                          81.7 Mbytesmax cache size                     976.6 Mbytes

可以看到,显然只有第二编次译时cache命中了,cache miss是第一次和第三次编译带来的。两次cache占用了81.7M的磁盘,还是完全可以接受的。

  • distcc

一台机器的能力有限,可以联合多台电脑一起来编译。这在公司的日常开发中也是可行的,因为可能每个开发人员都有自己的开发编译环境,它们的编译器版本一般是一致的,公司的网络也通常具有较好的性能。这时就是distcc大显身手的时候了。

使用distcc,并不像想象中那样要求每台电脑都具有完全一致的环境,它只要求源代码可以用make -j并行编译,并且参与分布式编译的电脑系统中具有相同的编译器。因为它的原理只是把预处理好的源文件分发到多台计算机上,预处理、编译后的目标文件的链接和其它除编译以外的工作仍然是在发起编译的主控电脑上完成,所以只要求发起编译的那台机器具备一套完整的编译环境就可以了。

distcc安装后,可以启动一下它的服务:

/usr/bin/distccd --daemon --allow 10.64.0.0/16

默认的3632端口允许来自同一个网络的distcc连接。

然后设置一下DISTCC_HOSTS环境变量,设置可以参与编译的机器列表。通常localhost也参与编译,但如果可以参与编译的机器很多,则可以把localhost从这个列表中去掉,这样本机就完全只是进行预处理、分发和链接了,编译都在别的机器上完成。因为机器很多时,localhost的处理负担很重,所以它就不再“兼职”编译了。

export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"

然后与ccache类似把g++,gcc等常用的命令链接到/usr/bin/distcc上就可以了。

在make的时候,也必须用-j参数,一般是参数可以用所有参用编译的计算机CPU内核总数的两倍做为并行的任务数。

同样测试一下:

一台双核计算机,make -j4:23分16秒

两台双核计算机,make -j4:16分40秒

两台双核计算机,make -j8:15分49秒

跟最开始用一台双核时的23分钟相比,还是快了不少的。如果有更多的计算机加入,也可以得到更好的效果。

在编译过程中可以用distccmon-text来查看编译任务的分配情况。distcc也可以与ccache同时使用,通过设置一个环境变量就可以做到,非常方便。

总结一下:

  • tmpfs: 解决IO瓶颈,充分利用本机内存资源
  • make -j: 充分利用本机计算资源
  • distcc: 利用多台计算机资源
  • ccache: 减少重复编译相同代码的时间

这些工具的好处都在于布署的成本相对较低,综合利用这些工具,就可以轻轻松松的节省相当可观的时间。上面介绍的都是这些工具最基本的用法,更多的用法可以参考它们各自的man page。

Git fetch和git pull的区别

March 24th, 2021

Git中从远程的分支获取最新的版本到本地有这样2个命令:
1. git fetch:相当于是从远程获取最新版本到本地,不会自动merge

git fetch origin master
git log -p master..origin/master
git merge origin/master
以上命令的含义:
首先从远程的origin的master主分支下载最新的版本到origin/master分支上
然后比较本地的master分支和origin/master分支的差别
最后进行合并
上述过程其实可以用以下更清晰的方式来进行:

git fetch origin master:tmp
git diff tmp
git merge tmp
从远程获取最新的版本到本地的test分支上
之后再进行比较合并
2. git pull:相当于是从远程获取最新版本并merge到本地

git pull origin master

上述命令其实相当于git fetch 和 git merge
在实际使用中,git fetch更安全一些
因为在merge前,我们可以查看更新情况,然后再决定是否合并

centos(Linux)扩容root分区

March 19th, 2021

vmware虚拟机装了个centos,用着用着硬盘不足,需要扩容。

首先在vmware中设置扩容,比如我的从20G扩招到30G,但是这样的设置之后,centos的空间没有变化,需要手动在Linux中扩容。

2020-03-04 at 4.49 PM.png

目前磁盘中新增的10G还为启用

操作1

增加了空间的硬盘是 /dev/sda 分区:

  • # fdisk /dev/sda
    p       查看已分区数量(我看到有两个 /dev/sda1 /dev/sda2)
    n       新增加一个分区
    p       分区类型我们选择为主分区
    分区号输入3(因为1,2已经用过了,sda1是分区1,sda2是分区2,sda3分区3)
    回车      默认(起始扇区)
    回车      默认(结束扇区) t
    修改分区类型        选分区3
    8e       修改为LVM(8e就是LVM)
    w       写分区表
    q
    完成,退出fdisk命令 使用partprobe命令 或者重启机器
2020-03-04 at 4.51 PM.png

增加了10G的sda3

进入lvm,通过vgdisplay查看组名:为centos

2020-03-04 at 4.53 PM.png
2020-03-04 at 5.10 PM.png

操作2

  • lvm             #进入lvm管理
    lvm>pvcreate /dev/sda3   #这是初始化刚才的分区3
    lvm>vgextend centos /dev/sda3 #将初始化过的分区加入到虚拟卷组centos (卷和卷组的命令可以通过 vgdisplay )
    lvm>vgdisplay -v或者vgdisplay查看free PE /Site
    lvm>lvextend -l+2559 /dev/mapper/centos-root  #扩展已有卷的容量(2559 是通过vgdisplay查看free PE /Site的大小)
    lvm>pvdisplay #查看卷容量
    lvm>quit  #退出
2020-03-04 at 5.07 PM.png
2020-03-04 at 5.01 PM.png

操作3

xfs_growfs /dev/mapper/centos-root扩容

2020-03-04 at 5.03 PM.png

这时候查看,扩容10G完成

2020-03-04 at 5.04 PM.png

Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist 问题解决

March 18th, 2021

需要首先更新源

./scripts/feeds update -a

其次 添加

./scripts/feeds install libpam

解决类似 /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found 的问题

March 18th, 2021

源码编译升级安装了gcc后,编译程序或运行其它程序时,有时会出现类似/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found的问题。这是因为升级gcc时,生成的动态库没有替换老版本gcc的动态库导致的,将gcc最新版本的动态库替换系统中老版本的动态库即可解决。

1. 问题原因分析

为了安装最新版本的Node.js(最新版本的Node.js使用了C++ 11中,而C++ 11需要code>gcc 4.8+才能支持),将gcc升级到了当前最新版本v 5.2.0。升级后,成功编译安装了新版本的Node.js(v 4.2.1),但运行时程序时出现了以下错误:

node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by node)
node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by node)
node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by node)

运行以下命令检查动态库:

strings /usr/lib64/libstdc++.so.6 | grep GLIBC

输出结果如下:

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

从以上输出可以看出,gcc的动态库还是旧版本的。说明出现这些问题,是因为升级gcc时,生成的动态库没有替换老版本gcc的动态库。

2. 问题处理

执行以下命令,查找编译gcc时生成的最新动态库:

find / -name "libstdc++.so*"

输出如下:

/home/gcc-5.2.0/gcc-temp/stage1-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so
/home/gcc-5.2.0/gcc-temp/stage1-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6
/home/gcc-5.2.0/gcc-temp/stage1-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.21  //最新动态库
……

/home/gcc-5.2.0/gcc-temp是升级gcc时的输出目录。

将上面的最新动态库libstdc++.so.6.0.21复制到/usr/lib64目录下:

cp /home/gcc-5.2.0/gcc-temp/stage1-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.21 /usr/lib64

复制后,修改系统默认动态库的指向,即:重建默认库的软连接。

切换工作目录至/usr/lib64:

cd /usr/lib64

删除原来软连接:

rm -rf libstdc++.so.6

将默认库的软连接指向最新动态库:

ln -s libstdc++.so.6.0.21 libstdc++.so.6

默认动态库升级完成。重新运行以下命令检查动态库:

strings /usr/lib64/libstdc++.so.6 | grep GLIBC

现在输出如下:

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBC_2.3
GLIBC_2.2.5
GLIBC_2.3.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

从零开始:编译自己的openwrt超详细教程

March 18th, 2021

网上关于openwrt的教程五花八门,很多新入门的选手并不清楚如何编译属于自己的openwrt固件,主要针对新手,按部就班进行,应该都是ok的。

因为家里正好有一台极路由3,本教程就以极路由3举例,进行本地编译。编译的版本是最新的openwrt19.07.1

准备工作

1、一个linux系统(可以自己虚拟机,我的系统是centos7,如果有谷歌云可以用谷歌云,毕竟省去翻墙)

2、一个梯子(编译时需要下载包,需要梯子)

第一步:虚拟机安装Centos并本地编译环境的安装

1、在虚拟机搭建一个linux系统(已经装好了可以跳过),这里用的centos7,不要快速安装,硬件按照自己配置选,一般选推荐即可。开进进入选择安装,选择最小安装,打开网络,点击开始安装。输入相应的root密码并创建一个用户,编译一定要在非root账户下进行,安装完成进入系统。

2、系统的更新,以及依赖包的安装,这部分都在root账号下,可以ssh远程登录,方便复制粘贴指令。mac下终端输入ssh [email protected]地址 即可

yum -y updateyum install -y gcc g++ build-essential asciidoc binutils bzip2 gawk gettext git libncurses5-devel libz-devel patch flex bison make autoconf texinfo unzip sharutils subversion ncurses-term zlib1g-dev ccache upx lib32gcc1 libc6-dev-i386 uglifyjs git-core gcc-multilib p7zip p7zip-full msmtp libssl-devel libglib2.0-dev xmlto qemu-utils automake libtool

3、安装最新的python3

因为centos自带的版本是2.7,编译需要python版本大于3.5

先查看你的python在哪里,进入python所在文件夹,查看软连接;

whereis pythoncd /usr/bin/ll python*

可以看到python指向的是python2,python2指向的是python2.7,因此我们可以装个python3,然后将python指向python3,然后python2指向python2.7,那么两个版本的python就能共存了

安装编译Python需要的环境

yum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel

安装pip

#运行这个命令添加epel扩展源yum -y install epel-release#安装pipyum install python-pip

用pip装wget

pip install wget

用wget下载python3的源码包

wget https://www.python.org/ftp/python/3.8.2/Python-3.8.2.tar.xz

编译python3源码包

#解压xz -d Python-3.8.2.tar.xztar -xf Python-3.2.2.tar#进入解压后的目录,依次执行下面命令进行手动编译./configure prefix=/usr/local/python3make && make install

python3安装完毕

#添加python3的软链接ln -s /usr/local/python3/bin/python3.6/usr/bin/python#测试是否安装成功了python -V

第二步:准备工作,一些信息的准备

访问openwrt官网 https://openwrt.org/ ,搜索你的路由器对应的型号,这里极路由3的型号是HC5861,查看你的硬件信息,极路由3是MediaTek MT7620A的平台,其实这里你会发现官方有已经编译完成的固件可以直接下载,咱不是要折腾么,嘿嘿嘿。。。懒得折腾的朋友可以根据自己路由器型号自行搜索,当然前提是你的路由器支持ssh登录刷系统哈,有一些官方的固件也会有问题,所以我们还是尽量选择自己编译。

第三步:下载官方源码

退出root用户,登入其他用户,创建openwrt文件夹,修改权限,进入文件夹,下载源码

mkdir openwrtsudo chmod 777 openwrtcd openwrtgit clone https://github.com/openwrt/openwrt.git source

第四步:更新源码

进入source文件夹,更新软件包,安装最新包

cd source./scripts/feeds update -a./scripts/feeds install -a

第五步:测试编译环境

make defconfig

第六步:开始编译

编译前关于平台、核心、型号的设置(第一二三大项);

make menuconfig

下面LuCI=》Modules=》Translations=》选择语言Chinese;

LuCI=》Applications=》选择需要的插件,这里只选择了ss,后续可以自己选择编译或者直接下载安装

选择完成后保存,开始编译,这里一定要有梯子,便已开始后会自动下载各种包,很多人失败的原因也就是这里。

make v=99

第一次编译耗时非常长也主要是因为要下载各种包(主要取决于网速,我第一次用了半天。。。。),第二次就快很多了

编译完成后的文件地址在/openwrt/source/bin/targets/ramips/mt7620/ 文件夹下,可以scp命令下载或者虚拟机可以共享文件夹直接拷贝,再或者虚拟机接个u盘,都可以

scp -r 用户名@服务器地址:/openwrt/source/bin/targets/ramips/mt7620/本地地址

Page 5 of 37...34567...
Meta
  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org
Categories
  • game
  • linux
  • news
  • pics
  • proxmox
  • windows
Recent Posts
  • 紧身胶衣问谁看不下贱?“HK416”:真的不鼓包的哦!~…
  • Using local directory bind mount points
  • Proxmox中Lxc容器挂载远程目录
  • livego流媒体服务实现无插件播放视频(支持hls,flv)
  • PVE直通核显给虚拟机
Recent Comments
  • Degebu on Proxmox中Lxc容器挂载远程目录
  • Bxdizx on Using local directory bind mount points
  • Markvem on livego流媒体服务实现无插件播放视频(支持hls,flv)
  • Eron Plus on livego流媒体服务实现无插件播放视频(支持hls,flv)
  • buy generic cialis online with mastercard on livego流媒体服务实现无插件播放视频(支持hls,flv)
Archives
  • April 2022 (1)
  • February 2022 (5)
  • January 2022 (2)
  • December 2021 (3)
  • November 2021 (1)
  • October 2021 (2)
  • September 2021 (1)
  • August 2021 (1)
  • July 2021 (8)
  • June 2021 (14)
  • May 2021 (2)
  • April 2021 (2)
  • March 2021 (10)
  • January 2021 (4)
  • December 2020 (4)
  • November 2020 (13)
  • April 2020 (276)
  • March 2020 (1)
  • June 2019 (5)
  • May 2019 (10)
  • December 2015 (1)