请教：调用informix的api函数后，api函数不返回问题

to 楼主：i
nformix的缓冲区占用了驻留内存中最大的部分。定义缓冲区的参数是BUFFERS。称作指定共享内存缓冲区的最大数目，该参数对数据库I/O和事务处理吞吐量有明显的影响。但是，如果分配过多的缓冲区会影响到操作系统的内存并导致过多的交换内存页面的活动。一般建议设置为物理内存的20％到25％。按照通常的说法

SHMVIRTSIZE定义了分配给Informix IDS共享内存的虚拟存储区的大小。一般考虑能满足一个日常操作的需要。
STACKSIZE指示了数据库服务器为每个活动线程指派的初始堆栈的大小。如果将该参数配置得过小，那么线程将无法拥有执行其程序的足够内存空间，而且它将干扰其他线程。
SHMADD定义了Informix IDS自动加到虚拟存储区的共享内存增量的大小。在增加共享内存时，要占用CPU周期；每次的增加量越大，增加次数就越少，留给其它的进程的内存也越少。所以一般采用大的增加量。但是在内存负荷很重时，少量增加使其他程序更好的共享内存资源。
所以是不是最好看下onconfig文件中的SHMVIRTSIZE，STACKSIZE，SHMADD参数。



命令 onstat -p是监控内存的另一个命令。其输出结果中的两个%cache显示了读写高速缓存比例的百分比，一般在80％到90％之间，如果低于80%，要调节BUFFERS参数值。ovlock 字段表明 IDS 在使用了最大数量的锁之后尝试过再使用锁的次数，如果该数字非零，可能需要提高配置文件中 LOCKS 参数的值。ovbuf 字段表明 IDS 在使用了最大数量的缓冲区之后尝试过再使用缓冲区的次数。如果该数字很大，比如说超过 100000，就需要提高 BUFFERS 参数，以便用户在需要从磁盘访问数据时不必等待缓冲区。在监控内存的使用情况时还可以采用Unix系统命令vmstat。

要是这些也不行的话，真的就不是很清楚了。收起

to：jillme
谢谢回复。
1. 我上面发的问题是阻塞在informix的库isqlt09a中，informix库的socket参数外面应用无法设置吧。
WS2_32!WSARecv+0x65   
WSOCK32!recv+0x31   
isqlt09a!service1+0xd932   
isqlt09a!service1+0xcaae   
isqlt09a!ifx_int8cmp+0xe441   
isqlt09a!ifx_int8cmp+0x1aab9   
isqlt09a!ifx_int8cmp+0x14002   
isqlt09a!ifx_int8cmp+0x770e   
isqlt09a!ifx_int8cmp+0x193b   
isqlt09a!CheckOsInit+0x1819   
isqlt09a!CheckOsInit+0x18f7   
isqlt09a!CheckOsInit+0x1db   
isqlt09a!sqli_defprep_set+0x483a
isqlt09a!sqli_prep+0x454   
isqlt09a!sqli_prep+0x1a8   
isqlt09a!sqli_prep+0x3f

2. 对于informix的socket数据收发是否是按你说的接受数据，估计只有informix的开发人员才比较清楚。

3. 我现在怀疑是不是informix的消息缓冲区不够导致，但怎么看informix的消息缓冲区？没有查到相关的命令。收起

估计你的程序中应该用到了SOCKET的通讯，你是用阻塞式的通讯还是非阻塞式的。
RECV时候，有没有考虑会是CSocket的缓冲区满了，Recv函数就是从这个缓存区中取出数据。当然，你也可以手动配置这个缓冲块的大小。使用setsockopt()设置SO_SNDBUF对象。再说你接受的字节数。如果在内部网络，一般你发多少就会收到多少。但是在网络环境不稳定的外网，有时TCP会把数据包分割开来给你发送出去（网速不稳定的时候经常如此）。你需要的是，接到数据后，判定一下数据包是否完整，是否需要继续等待接收。
一般的写法是，在数据包头前若干个字节包含了一个整包长度的int

当RECV接收到了 指定长度的包就可以停止了。收起

to：jillme
谢谢你的指点。

1. 我们经历的还有些不一样，我经历的是调用一个语句没有返回，也经历了一次在关闭数据库时不返回；
2. 我不知道你后来有没有再重现一下问题。即使连接没有关闭，再次连接应该只会报错或者超时，不会出现阻塞，我经历的至少过了（通过日志，分析代码逻辑）半个小时都没有返回；
3. 但我猜想的话，原因应该是类似的。
4. 我现在有一个猜测：会不会消息缓冲区不够导致？怎么看消息缓冲区？收起

你说的堵塞，我以前经历过1次，但是是堵塞在了数据库的连接上，但不知道你的情况是不是这样。上次连接的数据库，没有断开，EC中可以用多种方式去连接数据库，关闭的时候，也是一一对应的，否则会没有关闭上数据库，导致程序在次执行的时候，一直在尝试连接数据库。收起

没有人关注吗？自己再顶一下。收起

informix专家，请看过来！！收起

我现在有3个怀疑：1）有丢包，informix服务器没有收到应用程序的请求或者响应的请求应用程序没收到；2）informix内部有bug；3）informix的资源不够。
但这些都不好验证，只是猜测而已。收起

to：jillme
对应的IP和端口应该是开放了的，并且把我们的程序重启一下就可以恢复正常，下次什么时候再出现未知。
这次跑了一个多月，昨天又出来了。收起

这个还是检查下网络环境，是否开放了对应的IP,端口收起