在我们的生产系统上，我们最近丢了1TB的表。 删除完成后，表消失在mysql中，但文件仍然存在于/ lib / mysql / dbname /文件夹中。 （我们使用每个表设置一个文件）我删除了与表关联的文件。 所以我查了一下 lsof | grep crawl_link | grep deleted 发现mysql进程仍然有打开的句柄 mysqld 38115 mysql 11uW REG 8,3 1016938364928 182524780 /var/lib/mysql/seobility/_crawl_links_new.ibd (deleted) mysqld 38115 2110 mysql 11uW REG 8,3 1016938364928 182524780 /var/lib/mysql/seobility/_crawl_links_new.ibd (deleted) mysqld 38115 4530 mysql 11uW REG 8,3 1016938364928 182524780 /var/lib/mysql/seobility/_crawl_links_new.ibd (deleted) mysqld 38115 8192 mysql 11uW […]
我有一个小的数据库，支持大约3.5MB。 如果我覆盖了备份Tasks -> Backup -> Type: Full -> Backup to disk ，每增加3.5MB的大小。 如果我删除了现有的备份，然后按照上面的过程再次回到它的3.5MB大小。 我只注意到，因为我把我的开发数据库备份到Dropbox，它的大小达到了100MB。 这是一个错误？ 如果没有，发生了什么事？
问题 我们最近遇到了这样一种情况：我们的一些服务器实例突然用光盘空间不足了，如下图所示： 磁盘空间不足的原因是单个/tmp/magick-??? 文件，在几分钟内就会变成一个4GB的怪物。 系统设置 为了给我们的系统提供一些背景知识，我们运行了一个大型的rails应用程序，它使用mini_magick 4.7.1和carrier_wave ~0.11.0来通过后台作业执行产品图片上传。 意见 我们自然期待在服务器的使用寿命期间，图像上传会累积一些临时文件，这可以通过运行CarrierWave.clean_cached_files!来挽救CarrierWave.clean_cached_files! 定期。 有什么我们可能错过了？
我试图将我的数据备份到我的本地机器。 但是在文件复制过程中的某个时刻，我收到了这个令人讨厌的“设备上没有剩余空间”的错误信息。 df-Th输出： Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 5.9G 4.0K 5.9G 1% /dev tmpfs tmpfs 1.2G 1.5M 1.2G 1% /run /dev/sda5 ext4 156G 142G 6.2G 96% / none tmpfs 4.0K 0 4.0K 0% /sys/fs/cgroup none tmpfs 5.0M 0 5.0M 0% /run/lock none tmpfs 5.9G 179M 5.7G 3% /run/shm none tmpfs […]
这是发生了什么事： 我通过USB连接了一个外部硬盘 开始我的Vista机器 这花了很长的时间太多启动了大量的硬盘工作 我最终login了 内部系统磁盘重载并没有停止在接下来的几分钟，系统是非常反应，所以我点击开始>关机 分离的外部磁盘 开始机器与以前相同的症状 我100％确定外部磁盘没有被感染 我也尝试过在第二次login后closuresWindows Search服务（因为虽然这不能解释login点的exception启动时间，但我仍然可以进行磁盘索引）。 login后10分钟左右，服务仍处于启动模式。closures服务后，磁盘利用率没有消失。 所以我打开了（约5分钟后）。 我在Process Explorer（sysinternals）中检查了处理器利用率，但是处理器几乎在0％上。 有足够的免费系统内存，所以pagefile颠簸是不可能的。 并没有Windows更新，因为它是星期四和机器两天前已经更新（星期二定期更新）。 我的系统磁盘less于一半。 还有什么可能是错的？
我有8个SQL Server安装（在8个独立的服务器上）。 我想要一种可以估计未来磁盘空间需求的方法。 任何人都可以列出可以帮助做这种报告的参数吗？
我有一个软件raid1arrays（即镜像）中的两个120 GB磁盘，显示为/dev/md2 。 这里有一个ext3文件系统，安装在/ 。 # uname -a Linux svnserv 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64 GNU/Linux 最近，写入磁盘开始失败，出现“ 写入错误：设备上没有剩余空间 ”。 df显示没有更多的磁盘空间。 我删除了一些未使用的大文件，约。 5 GB，但错误仍然存在。 df显示了这个： # df -h Filesystem Size Used Avail Use% Mounted on /dev/md2 109G 104G 0 100% / tmpfs 471M 0 471M 0% /lib/init/rw udev 10M 100K 10M […]
我正在使用一个SQL Server 2005数据库，其中有一个文件组中的TempDB的8个文件。 第一个文件的初始大小是8MB，其他7个是2GB。 这个数据库是一个报告数据库，每晚从SSIS包中填入数据库。 包和报告使用了很多临时表。 这些文件已经增长到消耗大约300GB，均匀分布。 它将增长200MB无限制。 TempDB不备份，位于SAN上。 我读过你不应该在TempDB上使用SHRINKDATABASE或SHRINKFILE。 在这种情况下执行维护的正确方法是什么，以确保我们不会最大限度地减less磁盘空间并保持TempDB精简和平均。 感谢您的任何build议和知识。
我在服务器上的磁盘空间不足 – 我有一个包含大约20GB bkf文件的目录，这是ADAM存储的备份。 我正在考虑应用NTFS压缩文件夹来释放一些空间，这是一个徒劳无功的努力？ 谢谢！！
我有一个AIX服务器..分区应该有39GB的空间..但是当我做一个DF – K，它表明，我已经用完了几乎24GB的空间…但是，当我列出的一切下，挂载点..文件的大小不值得太多的空间..所以空间失踪到什么地方？ $ $ df -k Filesystem 1024-blocks Free %Used Iused %Iused Mounted on /dev/hd4 131072 4720 97% 1724 59% / /dev/hd2 1703936 541252 69% 34662 22% /usr /dev/hd9var 131072 76636 42% 484 3% /var /dev/hd3 1048576 1045528 1% 94 1% /tmp /dev/hd1 2097152 1361216 36% 16565 6% /home /proc – – – – […]