今天发现一个服务器的/opt目录数据过大,最后发现是tomcat中的catalina.out日志过大引起的 用du命令查看opt下一层的数据文件大小 [root@ccssapportalp opt]# du -h --max-depth=1 /opt 最终发现在tomcat里catalina.out的文件很大 [root@ccssapportalp logs]# ll -h /opt/liferay6.2ce/tomcat-7.0.42/logs/catalina.out -rw-r--r--

分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据 今天开发找我,说数据库insert不进数据,叫我看一下 他发了一个截图给我 然后我登录上服务器,发现了可疑的地方,而且这个数据库之前有一段经历 在月初的时候这个数据库曾经置疑过,启动不起来 Could ::), :), :), ). Page: LSN ::), type . , context , PrevPageLSN: (::). Restore from a backup of the database, or repa

发现好像这个方法不好使.......~~!还是会失败 如果有人或者自己失误把不该同步的大文件如数据或日志或其他中间文件给commit了并且push了,然后你删掉了,但是其实他仍然在你的git记录中,你的整个项目仍然会非常大,主要是当时的那个删除你没有用git rm,但总之你想清理就很麻烦了现在,或者说,可能现在由于你commit的东西太大,导致了根本没法push上去,会出现类似 fatal: the remote end hung up unexpectedly 这样的错误,然后你就是需要清理一

在log-driver是json-file的模式下,容器的日志存放在/var/lib/docker/containers/下面,是以container_id-json.log文件存放 但缺省方式下,log-driver是设置成journald,交给系统的journal服务来进行管理 日志限制可以通过docker option来进行,但是先要把log-driver修改成json-file模式 # cat /etc/sysconfig/docker OPTIONS='--log-driver=jso

数据库sqlplus能连接,plsql连接失败,也不报错,就定位到了是不是监听出了什么问题,删除监听,重建监听,重启监听,各种尝试都没解决问题. 却是监听日志太大导致的问题,一下是处理步骤: 查看监听日志的大小,位置如下:$ORACLE_BASE\diag\tnslsnr\\listener\trace\ 发现ORACLE的日志已经达到4G了,删除或重命名该日志 重启启动监听即可: lsnrctl stop  停止 lsnrctl start  启动 解决方法:关闭监听写日志 LSNRCTL>s

hadoop jobtracker日志太大在jobtracker服务器上的mapred-site.xml中添加以下参数: <property> <name>mapreduce.jobhistory.max-age-ms</name> <value>604800</value> </property> 然后重启hadoop,hadoop会自动删除7天之前的数据.

sqlserver使用在windows系统中,如果文件超上百GB了,我们还直接删除不了,这个问题我以前的apache日志就碰到过,至今还没删除呢,那么Sqlserver数据库日志太大如何快速删除呢,有没有办法,答案是肯定的,下面我给各位介绍两删除方法.   简单恢复模式下 使用backup log with NO_log是否没有意义?1.清空日志   DUMP  TRANSACTION  库名  WITH  NO_LOG   2.截断事务日志:   BACKUP LOG 数据库名 WITH NO

oracle导入命令,记录一下 工作中用到了,这个命令,记录一下,前提要安装imp.exe imp PECARD_HN/PECARD_HN@127.0.0.1:1521/orcl file=E:\work\dmp\PECARD_HN.dmp full=y 团队五人,专业从事软件开发,接单工作,专注于Java,.Net,PHP       数据库日志太大,清理日志文件 如果你的数据库出现如下场景,那么你需要对数据库进行日志清理了. 注:清理后的数据库,可能无法对数据库进行还原,所以,清理之前需要对

今天做我们的智能相冊的项目时,遇到了非常奇妙的问题,当照片太大时,导致ImageView.setImageBitmap不显示,上网上搜了非常多办法.感觉都不是那么靠谱.最后使用了简单粗暴的手段: //Bitmap too large to be uploaded into a texture Bitmap bm = BitmapFactory.decodeFile(imagePath); DisplayMetrics dm = new DisplayMetrics(); getWindowMan

即使在web.config中添加了节点和设置依然是不行的,还是报文件太大的错误, <httpModules>       <add name="UploadHttpModule" type="Brettle.Web.NeatUpload.UploadHttpModule, Brettle.Web.NeatUpload"/>     </httpModules>     <httpRuntime executionTimeou

使用了dojo开发.在datagrid过滤的时候.为了让过滤好处理,直接设置为完全二叉树的方式来存查询条件.但是在提交数据的时候,默认是get?url的方式.结果导致条件选择一两个,url会特别长.然后会报404错误.差点把前面的设计推掉,重来.项目就差一小部分了.时间上也来不及了.硬着头皮,看了一天的js源代码,我只能说,俺对js的世界无法理解啊.反复的试验了好久,硬是将rest的get请求,改为了post请求.代码如下: require(["dojo/_base/declare",

最近遇到个比较奇怪的问题,js函数里传参,传一个位数比较大,打印arguments可以看到传过来的参数已经改变. 然后查了一下,发现确实是js精度丢失造成的.我的解决方法是将数字型改成字符型传输,这样就不会造成精度丢失了.如下图: JS 数字丢失精度的原因 计算机的二进制实现和位数限制有些数无法有限表示.就像一些无理数不能有限表示,如 圆周率 3.1415926...,1.3333... 等.JS 遵循 IEEE 754 规范,采用双精度存储(double precision),占用 64 bi

机房有一台服务器上面部署了多个docker容器, 并且每个docker容器都往stderr中源源不断的输出日志,导致磁盘被占满了.Docker容器在启动/重启的时候会往/var/lib/docker中写数据,如果你在启动docker容器遇到"No space left on device"的问题,可以按照下面的步骤进行清理相关的日志操作. 1)对/var/lib/docker/containers下的文件夹进行排序,看看哪个容器占用了太多的磁盘空间 下面命令会按照升序的方式对于容器文件

1.登陆项目平台数据库服务器.双击SQL Server Management Studio打开数据库管理.登陆数据库 2.如下图,打开数据库属性窗口 3.如下图,更改数据库恢复模式 4.如下图,收缩数据库日志 到这里已经完成了,数据库的日志收缩 5.如下图,数据库恢复模式修改为完整

MongoDB的日志增长的非常快,/var所在的空间立即就占满了,即便换到还有一个磁盘分区保存日志.日志还是增长的非常快.磁盘眼看要告磬. 有一个好办法,就是使用旋转日志. MongoDB的旋转日志有点怪,Linux下mongd服务接受一个kill -SGIUSR1命令后就立马将当前日志文件重命名为带日期的文件.然后创建新的日志文件. 不想一般的旋转日志,能够配置旋转策略.只是没关系,经过測试,发送该命令时不会影响到MongoDB的服务. 以下是一个样例.先查找进程id, 然后发送命令. roo

首先,我们要确认日志的文件名,因为硬盘上的文件名不一定是数据字典里面的文件名,所以要确认下 USE test9572 GO SELECT file_id,name FROM sys.database_files; GO 然后就可以准备删了: USE [test9572] GO ALTER DATABASE test9572 SET RECOVERY SIMPLE WITH NO_WAIT GO --简单模式 ALTER DATABASE test9572 SET RECOVERY SIMPLE

http://www.cnblogs.com/littlestart/p/6023976.html

Cloning into 'large-repository'... remote: Counting objects: 20248, done. remote: Compressing objects: 100% (10204/10204), done. error: RPC failed; curl 18 transfer closed with outstanding read data remaining fatal: The remote end hung up unexpectedl

选中一个文件夹,例如node_modules,点击右键->mark directory as ->excluded,这样就可以把这个文件标记并排除出来,使webstorm不会扫描这个文件下面的文件,然后就可以很爽快的进入工作状态了.

今天在检查oracle rac集群时,突然才发现服务器的根目录下面占用了很多空间,照道理不应该出现这种情况,初步猜想可能是哪个日志或跟踪文件太大导致.切换到跟目录,使用du -sh *来一层一层查看到底是哪个文件占用了这么多空间,最后定位到目录/u01/app/11.2.0/grid/crf/db/<hostname>使用ls -lSrh对文件进行排序,发现“罪魁祸首”是crfclust.bdb [root@sz-db02 ~]# df -hFilesystem Size Used Avail

在post请求中数据太大导致报500错误.错误提示 JSON 请求太大,无法反序列化. 在config中加 <system.web.extensions> <scripting> <webServices> <jsonSerialization maxJsonLength="2147483644"></jsonSerialization> </webServices> </scripting> <