优化dstat监控日志

dstat是一个用来替换 vmstat,iostat netstat,nfsstat和ifstat这些命令的工具, 是一个全能系统信息统计工具。 因为实际使用起来,感觉不是很方便,因此作了一些修改,方便数据的采集和事后问题的排查。 用下面的命令来运行修改后的dstat(dstat代码下载) /home/oracle/dbafree/dstat -tydncs –output /home/oracle/dbafree/dstat.log –pidfile /home/oracle/dbafree/dstat.lck –nocolor 10 1.支持pidfile参数,并通过pidfile来防止并发执行。如果重复次启动dstat,会出现如下错误: pidfile ['/home/oracle/dbafree/dstat.lck'] is exist,process ['2350'] is running! Failed to create pidfile /home/oracle/dbafree/dstat.lck 0 2.自动记录dstat.log及自动收集元数据dstat_raw.log。 参数通过—output指定,dstat_raw.log自动根据output_raw.log来生成,–output必需以.log后缀结尾。 [oracle@testdb /home/oracle/dbafree] $ ls -ltr total 104 -rwxr-xr-x 1 oracle …

继续阅读 »

一个简单的python连接池,以及DBUtil.PooledDB的使用

写的一个很简单的连接池,基于线程安全的queue来实现,分享下: #使用DBUtils.PooledDB的oracle连接池 #使用DBUtils.PooledDB的mysql连接池 #一个统一的方法创建基于DBUtil.PooledDB的oracle或者mysql连接池:

一个多线程程序挂起问题解决

N个线程,做同样的事,跑的一直好好的,突然某个线程就挂住了。于是使用 ps -eLf|grep name查看了线程相关的PID,并对其进行了strace.如下: $ strace -p 13251 Process 13251 attached – interrupt to quit futex(0x1fcc500, FUTEX_WAIT_PRIVATE, 0, NULL 发现其一直hang在futex-FUTEX_WAIT_PRIVATE这里,可以看到futex一直在wait状态,长时间被挂起,就好象睡觉睡着了,没有人叫他起床。 我们的程序代码如下: while 1: #操作线程共享变量: #1.操作一个线程安全的队列 if(queue.size>0): queue.get() #2.操作线程不安全的hash结构,不过N个线程操作的key都是各不同的 #操作方式为hash{线程名}=xxx)。 hash{thread_name}=xxx 开始有点怀疑这个hash字典,因为非线程安全的,不过strace看到的是一个futex,那么应该和它关系不大,而跟线程安全的queue有更大的关系。因为futex可以对它进行保护。 于是先了解futex相关的情况,下面这段解释很清楚: Futex是一种用户态和内核态混合的同步机制。首先,同步的进程间通过mmap共享一段内存,futex变量就位于这段共享 的内存中且操作是原子的,当进程尝试进入互斥区或者退出互斥区的时候,先去查看共享内存中的futex变量,如果没有竞争发生,则只修改futex,而不 用再执行系统调用了。当通过访问futex变量告诉进程有竞争发生,则还是得执行系统调用去完成相应的处理(wait 或者 wake up)。简单的说,futex就是通过在用户态的检查,(motivation)如果了解到没有竞争就不用陷入内核了,大大提高了low-contention时候的效率。 FUTEX_WAIT: 原子性的检查uaddr中计数器的值是否为val,如果是则让进程休眠,直到FUTEX_WAKE或者超时(time-out)。也就是把进程挂到uaddr相对应的等待队列上去。 …

继续阅读 »

python 之queue

之前整过一篇:PYTHON和JAVA的线程同步的实现。多线程的问题总是涉及到线程同步问题。 python原生的list,dict等,都是not thread safe的。而queue,是线程安全的。Queue.Queue类即是一个队列的同步实现。今天有个需求,典型的“生产者消费者问题”,刚好可以用到queue,挺好用。 python queue模块有三种队列: 1、python queue模块的FIFO队列先进先出。 2、LIFO类似于堆。即先进后出。 3、还有一种是优先级队列级别越低越先出来。  针对这三种队列分别有三个构造函数: 1、class Queue.Queue(maxsize) FIFO  2、class Queue.LifoQueue(maxsize) LIFO  3、class Queue.PriorityQueue(maxsize) 优先级队列  介绍一下此包中的常用方法: Queue.qsize() 返回队列的大小  Queue.empty() 如果队列为空,返回True,反之False  Queue.full() 如果队列满了,返回True,反之False Queue.full 与 maxsize 大小对应  Queue.get([block[, timeout]])获取队列,timeout等待时间  Queue.get_nowait() 相当Queue.get(False) 非阻塞 Queue.put(item) 写入队列,timeout等待时间  Queue.put_nowait(item) 相当Queue.put(item, …

继续阅读 »

jdbc thin模式-bug 9373370分享

线上运行了几个月的thin模式,在一次flash卡芯片卡的故障中,暴露了一个比较严重的BUG。 这个bug严格来说非是thin驱动本身的bug。主要是服务端返回游标可能在ora-01013错误场景下可能会串掉,而客户端jdbc中并不能识别这个有问题的游标,所以导致客户端执行了错误的游标,具体请看bug描述。 BUG描述: Bug 9373370  The wrong cursor may be executed by JDBC thin following a query timeout / ORA-3137 [12333] Affects: Product (Component) Oracle Server (Rdbms) Range of versions believed to be affected Versions BELOW 12.1 Versions confirmed as being affected 11.2.0.2 11.2.0.1 11.1.0.7 …

继续阅读 »

使用fio工具对ssd/fio/verident/本地盘的压测结果,仅供参考

去年压测的,机器应该是R910,时间有点久了。最近整理了下,发到blog上来了。自己mark下,结果仅供参考。 也用orion压过,但发现单个进程Orion压不上去,启多进程就可以压上去了。猜想 :orion内部虽然是多线程的,但也许是单进程资源限制(也许受内部实现的限制,如进程对内存等有限制等)。 硬盘压测的iodepth都为32。 从数据可以得出: 使用传统磁盘,要发挥盘的性能,需要起88个线程,才能将其吞挥量发挥到最大,但Aio只需要4个线程。 使用pcie flash卡,只需要8个线程就可以发挥卡的60%以上的卡能力。Aio只需要4-8个线程即可发挥全部性能。 因为iodepth的深度问题,aio的延时会大很多。所以对于我们的软件,如果我们只需要10w的iops,那么考虑psync可能也是一个不错的选择,因为延时可以有所下降的。具体还是要依场景而定。(ps:Oracle本身都是aio,所以这块知识仅当作学习参考了。) ssd3700 Ssd数据是写满的情况下,使用fio压测工具压测的结果: 不管是aio还是psync,在随机写方面,均有超过理论值。 aio,在16线程上可以达到最大IOPS: 4k 随机读   iops:   44158        延时:7ms     理论值: 75,000 4k 随机写   iops: 37165          延时:8ms     理论值:36,000 8k随机读    iops: 38955          延时:8ms     理论值: 47,500 8k 随机写   iops: 23928          延时:19ms   理论值: 20,000 系统资源较闲,所以psync在IOPS上比aio更好,延时在us级别。 …

继续阅读 »

oracle 服务端连接池

在查看jdbc的connetion pool时看到了oracle server端实现的connection pool:文章:“Configuring Database Resident Connection Pooling”(这个我理解上应该就是一个pool) 上面的文档解释的非常清楚。 一般应用端基本上都实现了connetion pool,oracle端实现的pool,意义就并不是很大了,也许我们可以用它来预防连接风暴,有其它应用场景的也可以探讨一下。(如果解决连接数的问题,我们可以使用mts) 目前Oracle也支持一个连接池,pool name为“SYS_DEFAULT_CONNECTION_POOL”,管理连接池信息的也就一个包“DBMS_CONNECTION_POOL”。 先看看包的相关说明: SQL> desc DBMS_CONNECTION_POOL Element Type —————- ——— ALTER_PARAM PROCEDURE CONFIGURE_POOL PROCEDURE RESTORE_DEFAULTS PROCEDURE START_POOL PROCEDURE STOP_POOL PROCEDURE 包里面有5个存储过程。默认Oracle是包含一个缺省的连接池SYS_DEFAULT_CONNECTION_POOL,但是并没有被打开,需要显示的开启连接池,第一步当然就是开启连接池: exec DBMS_CONNECTION_POOL.START_POOL(‘SYS_DEFAULT_CONNECTION_POOL’); 这个操作只需要做一次,下次数据库重启了之后连接池会自动开启的。 打开了连接池之后可以通过系统视图dba_cpool_info进行查询: SQL> select connection_pool,status from …

继续阅读 »

linux的ulimit限制详解

文章来源于网上,不知出处,自己也测了下,分享下: ulimit的修改: 我们一般可以通过ulimit命令或编辑/etc/security/limits.conf重新加载的方式使之生效。 通过ulimit命令比较直接,但只在当前的session有效。 修改limits.conf中可以根据用户和限制项使用户在下次登录中生效。 对于limits.conf的设定是通过pam_limits.so的加载生效的,比如/etc/pam.d/sshd,这样通过ssh登录时会加载limit。 也可以在/etc/pam.d/login加载中生效,或者在profile中进行设置也可以。 下面将对各种限制进行分析: [root@testulimit]# ulimit -a #限制core文件的大小(core file size):指定为0,将不会产生core文件。对于产生的core文件,使用gdb –core corefile.name来观察 core file size (blocks, -c) 0 #限制进程使用数据段的大小(data seg size): 会影响程序调用brk(系统调用)和sbrk(库函数)。调用malloc时,如果发现vm不够了就会用brk去内核申请。单位为kb data seg size (kbytes, -d) unlimited #进程优先级的限制:这个值只对普通用户起作用,对超级用户不起作用。 测试如下nice -n -11 ls /tmp scheduling priority …

继续阅读 »

oracle filesystemio_options参数

今天同事咨询一个问题,大概是一个6g的表,dbcache为2g,数据文件在文件系统上,作全表扫描时速度差别很大: 库1:全表扫7秒 库2:全表扫1分10秒 硬件情况基本一致,使用iostat看了下设备上的IO,发现库1基本没有read,而库2的read很高。 再查看下文件系统cache,发现库2的文件系统cache一直不是很大,而且很稳定。因此怀疑和文件系统cache有关。查看参数filesystemio_options: 库1上设置为none,启用了文件系统cache,数据在文件系统cache中,性能较好。 库2上设置为set_all,使用了direct I/O,绕过了文件系统cache,所以数据没有在文件系统的cache中,性能会更差。 filesystemio_options说明如下: ASYNCH – Enabled asynchronous I/O where possible. DIRECTIO- Enabled direct I/O where possible. SETALL- Enabled both direct I/O and asynchronous I/O where possible. NONE – Disabled both direct I/O and asynchronous …

继续阅读 »

JDBC系列5- 超时控制

在jdbc query-time-out理解一文中已经对query-time-out的原理进行了一些阐述,本文介绍如何设置这些具体的参数。 对于已经连接的连接,java的connection property中提供了2个参数: “oracle.net.READ_TIMEOUT” 和”oracle.jdbc.ReadTimeout”。 在oracle的文档中 指出oracle.net.READ_TIMEOUT 这个参数更加通用,而oracle.jdbc.ReadTimeout则是给thin使用的. 某些版本下这两个参数都可以工作,但是经过测试发现oracle 11g中不能使用 oracle.net.READ_TIMEOUT,只能使用oracle.jdbc.ReadTimeout。这个问题让我今天排查了好久。 在connection的property中启用这些参数如下,针对于thin的情况,当然oci也可以使用。 Properties props = new Properties(); // 11g  thin使用这个 props.put(“oracle.jdbc.ReadTimeout”, “60000″); // 10g thin使用这个 // props.put(“oracle.net.READ_TIMEOUT”, “60000″); // 代表新建连接不能建立时的超时时间,这个参数,只有11g的驱动才能支持。 props.put(“oracle.net.CONNECT_TIMEOUT”, “10000″); // conn = DriverManager.getConnection(dbUrl, props); 另外oci,我们还可以在客户端建一个sqlnet.ora文件,在sqlnet.ora里来控制oracle net中的超时(具体可以参考相关的oracle文档),举例说明如下: …

继续阅读 »

普人特福的博客cnzz&51la for wordpress,cnzz for wordpress,51la for wordpress