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 …
一个多线程程序挂起问题解决
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文档），举例说明如下： …
近期评论