2015-04-13 17:36:56 u010022051 阅读数 751

对于使用Linux系统的初级用户,本文提供了查看Linux硬盘,内存的命令。有时系统缓存cache太大,严重影响了内存使用,本文提供了如何释放缓存的方法。

查看硬盘大小及剩余空间命令 df -h .

如下图所示,当前文件系统共有130G,使用了107G,还有17G剩余。

Linux文件系统查看硬盘,内存,释放缓存命令



查看当前文件夹大小

首先要切换到要查看大小的文件夹下,如cd dir

再执行命令 du -ch|grep total

Linux文件系统查看硬盘,内存,释放缓存命令


如上图所示,dir文件夹的大小为4.0K。

查看内存大小及缓存多少命令:free -m

Linux文件系统查看硬盘,内存,释放缓存命令


如上图所示,当前系统内存3963M,约合4G。已使用1568M,还剩余2394M,缓存(cache)有390M。

释放缓存,使用一组共三条命令:

echo 1 > /proc/sys/vm/drop_caches

echo 2 > /proc/sys/vm/drop_caches

echo 3 > /proc/sys/vm/drop_caches

Linux文件系统查看硬盘,内存,释放缓存命令


我们再查看内存,会发现cache的变少了,但是cache不会变成0。

Linux文件系统查看硬盘,内存,释放缓存命令


2018-09-18 07:46:35 M2l0ZgSsVc7r69eFdTj 阅读数 436

640

某信息安全机构披露Alpine Linux当中存在一项远程代码执行缺陷,而这一发行版目前正在众多Docker容器内得到广泛应用。
众包Bug赏金系统Bountygraph缔造者兼研究员Max Justica于上周四表示,此项漏洞可能被恶意攻击者利用,通过中间人(简称MITM)网络访问或操作恶意软件包镜像经由apk(Alpine的默认软件包管理器)实现任意代码注入。
Justicz指出,这一漏洞特别危险。首先,由于体积小巧,因此Alpine被广泛应用于各类Docker镜像。第二,大多数软件包apk都没有通过安全的TLS连接提供服务,因此极易受到篡改。
在最糟糕的情况下,攻击者能够在Docker镜像构建过程中拦截apk的打包请求,向其中注入恶意代码,而后将其传递至目标计算机。这些计算机会对软件包进行解压缩,并在Docker容器当中运行这些代码。
Justicz在接受采访时指出,“在Alpine的默认配置当中,如果我们能够运行「apk」命令的机器进行流量MITM攻击,即可使该机器执行任意代码。甚至在恶意代码开始运行之后,我仍然可以成功执行Docker build命令。”
“一旦攻击者在已经构建的镜像上执行其代码,则在该镜像后续开始运行后,其即可对目标计算机加以全面控制。”
此项安全漏洞源自apk解压归档文件以及处理可疑代码的具体方式。Justicz发现如果恶意软件可以隐藏在软件包的commit_hooks目录当中,则其将可逃避清理,而后得以正常执行。
这一结果意味着,上游恶意攻击者或者网络窃听者能够直接将恶意软件引入Docker容器,并在未经用户允许的情况下加以运行。此时,攻击者将在受害计算机上运行该代码,意味着其将能够针对目标容器或主机系统实施进一步攻击。
Alpine的最新版本已经对apk进行了修复更新,因此我们建议开人员利用经过更新的Alpine版本重构自己的Docker镜像。
原文链接:https://www.theregister.co.uk/2018/09/15/alpine_linux_bug/


Kubernetes实战培训

640?


Kubernetes应用实战培训将于2018年10月12日在深圳开课,3天时间带你系统学习Kubernetes本次培训包括:容器基础、Docker基础、Docker进阶、Kubernetes架构及部署、Kubernetes常用对象、Kubernetes网络、存储、服务发现、Kubernetes的调度和服务质量保证、监控和日志、Helm、项目实践等,点击下方图片查看详情。

640?

2019-11-08 23:34:36 ulver 阅读数 5

sql_cache

一个简单的缓存队列,使用linux的共享内存获得执行SQL字符串序列,放入到缓存队列中执行。

由于工作的原因,程序有大量的数据库操作(查询操作已经被缓存队列代替,剩下的都是插入、更新操作),严重影响程序效率。
由于这些数据库操作是顺序执行的,形成了序列,所以想到解决办法就是,将数据库操作字符串不断的放入共享内存中,由另外 一个单独运行的进程从共享内存中读取字符串序列并执行。
上传的代码是解决办法的简化版本,已经测试运行良好,具备一定的实用性。
上传的代码附带有测试代码,负责从文件中读取SQL字符串序列,并放入共享内存中。

代码下载地址

2016-04-28 14:28:35 hj960511 阅读数 964

问题描述:

:(
Allowed memory size of 1916796928 bytes exhausted (tried to allocate 3086655745 bytes)

错误位置

FILE: /data/xxx/ThinkPHP/Common/functions.php  LINE: 370

问题解决:
这个问题貌似不是php函数preg_replace_callback的bug。我的经过一天半的折磨,终于排查到原因了, 我的服务器环境加载了eaccelerator扩展;经过测试,只有在启用eaccelerator这个扩展后有关 preg_replace_callback的代码段就会内存溢出,而注释掉eaccelerator扩展后,P事没有。
eaccelerator的大坑啊!

注释:加速扩展影响的问题

2019-08-19 16:50:44 Listen2You 阅读数 22
导读 Linux 上的内存管理很复杂。尽管使用率高但未必存在问题。你也应当关注一些其他的事情。

Linux的内存用量Linux的内存用量
在 Linux 上用光内存通常并不意味着存在严重的问题。为什么?因为健康的 Linux 系统会在内存中缓存磁盘活动,基本上占用掉了未被使用的内存,这显然是一件好事情。
换句话说,它不让内存浪费掉。使用空闲的内存增加磁盘访问速度,并且不占用运行中应用程序的内存。你也能够想到,使用这种内存缓存比起直接访问硬盘驱动器(HDD)快上数百倍,也比明显快于直接访问固态硬盘驱动。内存占满或几乎占满通常意味着系统正在尽可能高效地运行当中 —— 并不是运行中遇到了问题。

缓存如何工作

磁盘缓存简单地意味着系统充分利用未使用的资源(空闲内存)来加速磁盘读取与写入。应用程序不会失去任何东西,并且大多数时间里能够按需求获得更多的内存。此外,磁盘缓存不会导致应用程序转而使用交换分区。反而,用作磁盘缓存的内存空间当被需要时会立即归还,并且磁盘内容会被更新。

主要和次要的页故障

Linux 系统通过分割物理内存来为进程分配空间,将分割成的块称为“页”,并且映射这些页到每个进程的虚拟内存上。不再会用到的页也许会从内存中移除,尽管相关的进程还在运行。当进程需要一个没有被映射或没在内存中页时,故障便会产生。所以,这个“故障fault”并不意味着“错误error”而是“不可用unavailables”,并且故障在内存管理中扮演者一个重要的角色。
次要故障意味着在内存中的页未分配给请求的进程,或未在内存管理单元中标记为出现。主要故障意味着页没有保留在内存中。
如果你想切身感受一下次要页故障和主要页故障出现的频率,像这样试一下 ps 命令。注意我们要的是与页故障和产生它的命令相关的项。输出中省略了很多行。MINFL 显示出次要故障的数目,而 MAJFL 表示了主要故障的数目。

$ ps -eo min_flt,maj_flt,cmd
 MINFL  MAJFL CMD
230760    150 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
     0      0 [kthreadd]
     0      0 [rcu_gp]
     0      0 [rcu_par_gp]
     0      0 [kworker/0:0H-kblockd]
   ...
   166     20 gpg-agent --homedir /var/lib/fwupd/gnupg --use-standard-socket --daemon
   525      1 /usr/libexec/gvfsd-trash --spawner :1.16 /org/gtk/gvfs/exec_spaw/0
  4966      4 /usr/libexec/gnome-terminal-server
  3617      0 bash
     0      0 [kworker/1:0H-kblockd]
   927      0 gdm-session-worker [pam/gdm-password]

汇报单一进程,你可以尝试这样的命令(LCTT 译注:参数里面的 1 是要查看的进程的 PID):

$ ps -o min_flt,maj_flt 1
 MINFL  MAJFL
230064    150

你也可以添加其他的显示字段,例如进程所有者的 UID 和 GID。

$ ps -o min_flt,maj_flt,cmd,args,uid,gid 1
 MINFL  MAJFL CMD                         COMMAND                       UID   GID
230064    150 /usr/lib/systemd/systemd -- /usr/lib/systemd/systemd --     0     0

多少才算满?

一种较好的方法来掌握内存究竟使用了多少是用 free -m 命令。-m 选项指定了数字的单位是 MiBmebibyte 而不是字节。

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3244        3069          35          49         140         667
Swap:          3535           0        3535

注意 free(未使用)的内存可能会不足,而 available(可用于启动新的应用)会显示更大的数量。这两者的区别值得我们去关注。可用available意味着它可以在需要时恢复使用,而空闲free意味着现在就能够使用。

什么时候要担心

如果 Linux 系统上的性能表现良好 —— 应用程序响应度高,命令行没有显示出问题 —— 很可能系统状况良好。记住,一些应用也许会出于某种原因而变慢,但它不影响整个系统。
过多的硬故障也许表明确实存在问题,但要将其与观察到的性能相比较。
一个好的方法是当可用内存接近 0 或者“用作交换swap used”项显著增长或波动时开始担心。如果“可用”项占总内存可用量的百分比合理,那么就无需担心,就像下面的例子那样:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3244        3069          35          49         140         667
Swap:          3535           0        3535

Linux 性能很复杂

抛开这些不说,Linux 系统上的内存可能会变满,并且性能可能会降低。当系统出现问题时不要仅将单一的内存使用报告作为指标。
Linux 系统的内存管理很复杂,因为它采取的措施需要确保系统资源得到最好的利用。不要受到一开始内存占满的欺骗,使你认为系统存在问题,但实际上并没有。

原文来自:https://www.linuxprobe.com/linux-memory-usage.html

没有更多推荐了,返回首页