首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏summerking的专栏

    软连接解决磁盘

    解决root磁盘满了,但是/home下还有很多空间 # 这里我们主要做两步操作就可以了 移动原有root磁盘下的summer目录至home目录下 [root@summer ~]# cd summer / [root@summer summer]# ll total 4 drwxr-xr-x 3 root root 4096 Oct 25 20:10 blog [root@summer summer] 这样我们就可以使其他利用到该目录的进程在无感知的情况下解决磁盘目录不足的问题了。

    1.2K20编辑于 2022-09-19
  • 来自专栏蓝天

    Linux磁盘问题分析

    线上一台Linux服务器最近经常磁盘根分区告警, 但不是普通的日志文件或数据文件过多过大,现象如下: 1)执行“df -h”查看各分区空间的使用情况 [root@XEN64            7.7G  666M  7.1G   9% /run tmpfs           7.7G     0  7.7G   0% /sys/fs/cgroup /dev/sda3        进入根目录,查看根目录下各子目录的大小: [root@XEN64 /]# du -sm * 0       bin 180     boot 0       dev 24      etc 3              REG        8,1 5969132048     409096 /tmp/process_monitor-root.log (deleted) stati 28885 root    3u REG        8,1 5969132048     409096 /tmp/process_monitor-root.log (deleted) consumer 29756 root    3u

    3.2K31发布于 2018-12-28
  • 来自专栏Python自动化测试

    混沌工程之磁盘

    在上一个文章中详细了介绍了什么是混沌工程以及混沌工程执行的原则,和混沌工程实验中数据库调用延迟,下来详细的介绍另外一个混沌实验,也就是云服务器磁盘被写的情况的模拟实验和解决思路。 实验的核心是模拟当服务器的磁盘的情况下,这个时候服务器就会成为只读的属性。 比如举个案例,当DB的服务器磁盘的情况下,那么这个时候DB服务器就成为只读属性,这个时候产品使用的数据库由于成为了只读属性,意味着使用这个DB的服务器就会出现大面积的瘫痪导致服务不可用。 下来首先模拟下磁盘的操作,在操作前首先查看磁盘已使用的空间以及可使用的空间,具体如下: 系统资源整体性的监控信息具体如下图所示。 那么在如上的实验中,需要思考的是在磁盘的情况下需要很快速的触发报警机制,然后来排查到底是什么原因导致磁盘空间写以及针对情况需要给出具体的技术解决方案,同时也要能够快速的切换到一个正常的服务器继续让产品的服务能够提供服务

    94630编辑于 2022-12-03
  • 来自专栏编程一生

    Elasticsearch实战-磁盘IO被打

    团队,最终得到下面的答复: 当前集群现状: 1)当前集群数据IO最高的索引为XXX,数据量很小(100mb) 2)但是读写都很大(读>1000QPS,写>1000QPS) ,使用的是线下环境的机器 3) 分析: 1)线下环境的机器之前了解到测试环境硬盘性能本来就很差,这个需要业务SRE一块来确定 2)查询的时候,会一次性查询10个片,这样可能会查10台机器的数据,很容易出现木桶效应,造成集群的性能下降 3) 测试环境ES有十台VM(非本地ESB磁盘)作为服务器。其中一台IO被打。其他机器负载、IO都很低。 只能继续沿用老的客户端使用; 我们预计在10月份左右会出一个自研的客户端, 会尽量避免出现一台机器导致部分查询出现问题, 但是也避免不了, ES内部的服务发现机制,我们改变不了,除非改ES 调查 1.需要换成本地磁盘 3.程序方面有没有可以优化的? 在ES上层增加tair缓存。在进行数据更新操作时是单个数据读取。采用tair有更好的事务性,并减少了对ES的压力。ES只处理复杂查询请求。

    2.9K30发布于 2019-10-08
  • 来自专栏MySQL入坑记

    磁盘解决方式及思路

    上午同事反应MySQL连不上了,我到服务器上用"df -h"查一下磁盘,发现磁盘打满了。 解决顺便记录一下流程: 查看磁盘状态命令:df -h 查看目录下各文件(夹)所占磁盘大小命令:du -sh * 磁盘截图: ? 排查方式: 如图中Mount on所示,该磁盘在 "/" 根目录下,磁盘;因此我们基于 "/" 目录查询较大(>1G)的文件,处理掉即可。 purge master logs before date_sub(now(), interval 3 day); //清除3天前的bin日志 4、 修改my.cnf文件:在 log-bin=mysql-bin 下一行加上并重启MySQL:expire_logs_days=3 只保存近三天操作日志 ?

    1.3K21发布于 2020-07-08
  • linux磁盘,排查大文件

    公司服务器遇到磁盘空间不足,导致其他服务无法使用的情况,通过下列的linux命令进行排查,成功清理掉无用大文件,服务成功恢复。 查看磁盘空间使用情况 df -h 当前目录文件大小排序 du -sh * |sort -nr 进入占用比较大的目录,然后逐级定位到无用的大文件,通常是日志文件。

    1.2K10编辑于 2024-09-29
  • 一次磁盘的情况处理

    收到系统磁盘告警,查看告警机器,发现data目录已经满了:[root@VM-41-182-Linuxos /data]# df -hFilesystem Size Used Avail Use% Mounted 之后再次查看df,磁盘正常了:[root@VM-41-182-Linuxos /data]# df -hFilesystem Size Used Avail Use% Mounted ondevtmpfs 266M 7.5G 4% /runtmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup/dev/vda1 99G 11G 85G 11% //dev/vdb 296G 6.9G 274G 3% 只有当链接数量减少到零,并且没有任何进程打开该文件时,文件占用的磁盘空间才会被操作系统回收。这种设计允许应用程序在不影响其他进程的情况下删除文件,同时还能继续使用已删除文件的内容。 这里想说明的1、当磁盘满了df查不出原因的时候,使用du可以进一步分析各个目录的占用情况2、删除的文件句柄并不会立刻释放,当出现大量这种情况的时候,需要重启服务。

    41910编辑于 2024-10-21
  • 来自专栏一去紫台连朔漠

    centos磁盘空间的问题处理.

    1.接入监控系统监控磁盘空间信息. image.png 2.登录服务器查看磁盘空间情况(df -h) image.png 3.查询系统中的的大文件(cd / | du -h |sort -hr|head -30) image.png 4.删除系统中的不再使用大文件 5.根分区只能考虑删除多余文件.其他分区可考虑新增磁盘.把现有分区磁盘迁移到新磁盘.然后释放其他分区

    2.3K50发布于 2020-06-19
  • 来自专栏cwl_Java

    数据库PostrageSQL-磁盘失败

    磁盘失败 一个数据库管理员最重要的磁盘监控任务就是确保磁盘不会写。一个写满了的数据磁盘可能不会导致数据的崩溃,但它肯定会让系统变得不可用。 如果保存 WAL 文件的磁盘,会发生数据库服务器致命错误并且可能发生关闭。 如果你不能通过删除一些其他的东西来释放一些磁盘空间,那么你可以通过使用表空间把一些数据库文件移动到其他文件系统上去。 有些文件系统在快的时候性能会急剧恶化,因此不要等到磁盘完全的时候才采取行动。 如果你的系统支持每用户的磁盘份额,那么数据库将自然地受制于用户所处的服务器给他的份额限制。 超过份额的负面影响和完全用光磁盘是完全一样的。

    1K30发布于 2021-08-30
  • 来自专栏upuptop的专栏

    记一次 mysql 磁盘解决过程

    一系列神操作 备份数据库,删除实例、删除数据库表、重启mysql服务.结果磁盘空间均为释放 怎么办 网上查了很多资源,说要进行磁盘碎片化整理。原因是datafree占据的空间太多啦。 /abc 5、重新启动mysql 发现磁盘空间释放了 service mysql start 磁盘空间终于释放了 下一步数据库还原 1、采用navicate备份工具,进行数据库备份 ? 3、然后对备份数据库进行还原,点击还原 ? 4、开始进行还原 第一次还原后发现还原后数据库表建成功了,但是表里面没有数据。 后来网上查找资料发现是,遇到错误就停止了。 ,会使这种留空的空间变得比存储列表内容所使用的空间更大; (2)当执行插入操作时,MySQL会尝试使用空白空间,但如果某个空白空间一直没有被大小合适的数据占用,仍然无法将其彻底占用,就形成了碎片; (33.清理student的105万条数据, OPTIMIZE TABLE 库.student;本地测试需要37秒。

    2.5K10发布于 2020-12-15
  • 来自专栏YP小站

    Kubernetes之容器数据写磁盘解决方法

    磁盘引发的后果 容器数据磁盘造成的后果: Pod 不能删除 (一直 Terminating) Pod 不能被创建 (一直 ContainerCreating) 磁盘写满分两种情况: 磁盘空间全部使用完 被占满 $ df -i 文件系统 Inode 已用(I) 可用(I) 已用(I)% 挂载点 /dev/vda1 3276800 3276800 0 100% / 判断磁盘方法 # 取消不可调度的标记 $ kubectl uncordon ${node-name} 定位问题根本原因及解决思路 日志输出量大,导致磁盘 减少日志输出,调整应用日志输出级别 增大磁盘空间 日志输出到统一日志收集中心 容器镜像占满磁盘 配置k8s垃圾回收策略 节点运行 images 定时清理脚本 可写层量大导致磁盘: 优化程序逻辑,不写文件到容器内或控制写入文件的大小与数量 具体优化方法 配置 Docker日志轮转 registry-mirrors 镜像加速配置 graph 定义数据存储目录 max-size=500m 意味着一个容器日志大小上限是500M max-file=3,意味着一个容器有三个日志,分别是id

    3.3K10发布于 2020-06-04
  • 来自专栏云原生知识宇宙

    Kubernetes 最佳实践:处理容器数据磁盘被写

    容器数据磁盘被写造成的危害: 不能创建 Pod (一直 ContainerCreating) 不能删除 Pod (一直 Terminating) 无法 exec 到容器 判断是否被写: 容器数据目录大多会单独挂数据盘 判断是否被写: $ df Filesystem 1K-blocks Used Available Use% Mounted on ... restart dockerd 取消不可调度的标记: kubectl uncordon 10.179.80.31 定位根因,彻底解决 问题定位方法见附录,这里列举根因对应的解决方法: 日志输出量大导致磁盘 : 减少日志输出 增大磁盘空间 减小单机可调度的pod数量 可写层量大导致磁盘: 优化程序逻辑,不写文件到容器内或控制写入文件的大小与数量 镜像占用空间大导致磁盘: 增大磁盘空间 删除不需要的镜像 附录 查看docker的磁盘空间占用情况 $ docker system df -v [docker-system-df.png] 定位容器写磁盘的原因 进入容器数据目录(假设是 /var/lib/

    1.2K11发布于 2019-06-08
  • 来自专栏Kirito的技术分享

    Linux 环境写文件如何稳定跑磁盘 IO 带宽?

    在 限制内存 的情况下,假定我们每次写入 4k 的数据,如何保证 kill -9 不丢数据的情况下,仍然稳定的跑磁盘的 IO? 又因为限制内存,所以直观的想法是直接 Direct IO, 但 Direct IO 能否跑磁盘 IO 呢? 机器配置 CPU: 64 核 Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz 磁盘 : Intel Optane SSD 测试磁盘 IO 性能 官方称读 / 写带宽是 通过数据我们发现,单次 4k 的 Direct IO 写入无法跑磁盘的 I/O 带宽,仅仅只有 800MB/S 实验三: mmap 写入 通过前面这两个实验我们发现,Buffer IO 是可以跑磁盘 4096; } UnMapRegion(base); close(data_fd); } 我们通过 vmstat 来获取写入带宽数据,我们发现 mmap 的 16K 写入可以跑磁盘带宽

    7.8K11发布于 2019-10-30
  • 来自专栏云原生知识宇宙

    Kubernetes 最佳实践:处理容器数据磁盘被写

    容器数据磁盘被写造成的危害: 不能创建 Pod (一直 ContainerCreating) 不能删除 Pod (一直 Terminating) 无法 exec 到容器 判断是否被写: 容器数据目录大多会单独挂数据盘 判断是否被写: $ df Filesystem 1K-blocks Used Available Use% Mounted on ... restart dockerd 取消不可调度的标记: kubectl uncordon 10.179.80.31 定位根因,彻底解决 问题定位方法见附录,这里列举根因对应的解决方法: 日志输出量大导致磁盘 : 减少日志输出 增大磁盘空间 减小单机可调度的pod数量 可写层量大导致磁盘: 优化程序逻辑,不写文件到容器内或控制写入文件的大小与数量 镜像占用空间大导致磁盘: 增大磁盘空间 删除不需要的镜像 附录 查看docker的磁盘空间占用情况 $ docker system df -v [docker-system-df.png] 定位容器写磁盘的原因 进入容器数据目录(假设是 /var/lib/

    4.2K32发布于 2019-06-08
  • YashanDB|磁盘被 archivelog 写?教你快速排查与应对!

    在日常使用 YashanDB 数据库时,有些用户会遇到这样的问题:数据库突然变成 abnormal 状态,一检查才发现是 archivelog 写导致磁盘空间耗尽。 ,确认磁盘空间已被 archivelog 日志彻底占满。 简单来说,就是因为缺乏归档日志管理机制,archivelog 像“雪球”一样越滚越大,直到把磁盘压垮。三、解决与规避方法1. 立即处理临时释放空间:手动删除旧的、不再需要的 archivelog 文件;恢复数据库:释放足够磁盘空间后,重启数据库,恢复到 normal 状态。2. 五、小结提醒在部署 YashanDB 数据库时,务必同步规划好归档日志管理策略;测试环境虽然数据不重要,也要做好基本的日志清理机制;日常运维中,定期检查磁盘空间使用情况,避免意外宕机。

    17500编辑于 2025-04-28
  • 来自专栏DB说

    磁盘空间导致(空间释放后)GOLDENGATE进程无法启动

    【背景】 最近有朋友反馈说OGG所在磁盘空间,手动清理磁盘空间后,无法启动OGG进程,当时想想不应该,以前遇到很多次,空间后,手动清理空间,如果mgr配置自启动或者手动启动进程,都是瞬间搞定 2、【怀疑是进程的文件存在问题导致】 一般是操作系统异常重启或者磁盘空间,ogg进程出现假死情况,ogg进程启动后记录一个文件(类似lock文件),手动删除还是不行,基本上确认不是进程假死造成的 3、【OGG却可以通过os命令启动--ggsci底层也是调用os命令】 extract PARAMFILE /ogg/dirprm/dumptest.prm REPORTFILE /ogg/dirrpt extract PARAMFILE /ogg/dirprm/exttest.prm REPORTFILE /ogg/dirrpt/EXTTEST.rpt 再次验证ogg状态 GGSCI (test) 3> datastore出现问题,只能重建】 --停止所有进程包括mgr和jagent GGSCI (TEST) 1>stop * GGSCI (TEST) 2>stop jagent GGSCI (TEST) 3>

    2.1K10发布于 2020-08-03
  • 来自专栏YashanDB知识库

    【YashanDB知识库】archivelog磁盘导致数据库abnormal

    【问题分类】功能使用【关键字】磁盘空间,archivelog日志,archivelog自动清理【问题描述】数据库状态变更为abnormal,检查V$DIAG_INCIDENT视图,发现提示信息为archive 日志无法正常写入,磁盘无剩余空间。 【问题原因分析】测试环境未配置备份,archivelog自动清理的忽略模式为默认值NONE,导致一直没有触发archive日志自动清理的机制,archivelog占用空间持续膨胀,直到占满磁盘

    20100编辑于 2025-02-24
  • 来自专栏DBA随笔

    线上磁盘导致MySQL复制失败案例一则

    // 线上磁盘导致MySQL复制失败案例 // 01 案例场景 今天在线上发现一个问题,由于监控没有覆盖到,某台机器的磁盘被写满了,导致线上MySQL主从复制出现问题。 out of disk space" 02 解决问题 登录服务器,很快就发现是MySQL所在的服务器磁盘使用率达到100%了,问题原因跟error log中的内容一致。 master to master_host='10.13.224.31', -> master_user='replica', -> master_password='eHnNCaQE3ND 03 一点总结 当磁盘的情况发生之后,mysql服务无法向元信息表中写数据,relay log也可能已经不完整了,如果直接清理了服务器上的磁盘数据,再去重新change master修改主从复制关系 所以,正确的做法应该是: 1、清理服务器的磁盘 2、重启复制关系断开的那个从库 3、重新reset slave all、change master来搭建主从复制关系即可 如果有更好的方法,还请不吝赐教

    1.1K20发布于 2021-04-22
  • 来自专栏首富手记

    企业故障案例:Web服务器磁盘深入解析及解决

    ######################################################### # 硬盘显示被写但是用du -sh /*查看时占用硬盘空间之和还远 #小于硬盘大小问的解决 : http://oldboy.blog.51cto.com ########################################################## 问题:硬盘显示被写, 但是用du -sh /*查看时占用硬盘空间之和还远小于硬盘大小 即找不到硬盘分区是怎么被写的。 可空间还是的,情况危急啊。这个问题,在多年以前直接和间接的遇到过3-4次。以前太懒惰了,这次记录下来和大家分享。 2109       17849   126439582+  83  Linux [root@www /]# fdisk -l /dev/sda3 Disk /dev/sda3: 129.4 GB, 129474132480

    1.3K30发布于 2018-09-10
  • 来自专栏数据和云

    【MySQL】磁盘之后,数据库show status受到阻塞的原因

    编辑手记:前两天同事讨论到一个问题,当mysql从库磁盘之后,show status及show slave status会被卡住,但其他select操作不受影响,但如果数据库是主库,磁盘满了之后,只有 2.下文中提到的磁盘,指的是数据文件(数据文件,日志文件,配置文件)所在磁盘分区。 3.由于篇幅问题,最后面的代码部分,只有关键的函数及逻辑判断部分。 2.每十分钟给日志文件写入一条记录,报告磁盘已经写。 但是对不对? 上面是对主库所在磁盘之后,数据库实例的反应,下面讲讲我们遇到的情况:从库磁盘之后,show status及show slave status会被卡住,但其他select操作不受影响。 整个流程涉及3把锁: 1.mi->data_lock 2.LOCK_active_mi 3.LOCK_status 当一个新操作被接收到slave io线程后,如果这时候磁盘写满了,这个写入操作就会被阻塞

    2.6K60发布于 2018-03-07
领券