tusc reports Interrupted system call with Sybase

[Eric Guerizec]

Hello
We use Sybase 12 on HPUX 11i. For DBA, Sybase works well! But if I use tusc on the dataserver process, I see many lines like these :
[7791] select(0, NULL, NULL, NULL, 0xc0000000043672f0) ........................................................................... = 0
[7791] Received signal 14, SIGALRM, in select(), [caught], no siginfo
[7791] select(0, NULL, NULL, NULL, 0xc0000000043672f0) ........................................................................... ERR#4 EINTR

Error 4 is : Interrupted system call

Very strange, isn't it?
Someone can tell me what happens. Tkanks.

Eric

[Steven Gillard_2]

Ignore it - this behaviour looks normal. The process is obviously scheduling a SIGALRM prior to the select() call with either the alarm() or setitimer() system calls (you should see these earlier in the trace).

The EINTR is reported by select() because the requested SIGALRM is being delivered. It doesn't mean there's a problem.

Regards,
Steve

[David Child_1]

I am getting a very similar trace. Only for me the DBAs are complaining of very slow I/O.

HPUX 11.00, RP7400 8CPU & 12GB mem.

They are running an archive process from another server which they say just does a simple select statement. For a while Sybase reports I/O from 50-150/sec, but then it drops down to 1-2/sec for a while. I have been examining the server and don't see any real change. CPUs are very low, I don't see any hammered disks, file systems, LVs, etc. Memory appears okay. sar %WIO remains 0.

During the 'slow' times I did notice with tusc that the trace starts showing a lot of: "Received signal 14, SIGALRM, in select(), [caught], no siginfo" lines. When it is running 'ok' then those lines do not show up much.

Any ideas?

Thanks,
David

[David Child_1]

Thought I better show a little more detail:

[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] Received signal 14, SIGALRM, in select(), [caught], no siginfo
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] Received signal 14, SIGALRM, in select(), [caught], no siginfo
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] Received signal 14, SIGALRM, in select(), [caught], no siginfo
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0

Its not working too good right now so I can't get a good shot of that output. I will add it when I can.

David

[David Child_1]

Okay, its running a better at this time and this is the tusc output:

[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0
[7022] lseek(78, 18014748672, SEEK_SET) .................. = 18014748672
[7022] read(78, "04n 8 h 04n 8 i 04n 8 w b 13aef0".., 16384) = 16384
[7022] lseek(78, 18014732288, SEEK_SET) .................. = 18014732288
[7022] read(78, "04n 8 ` 04n 8 a 04n 8 o b 13aef0".., 16384) = 16384
[7022] lseek(78, 18014715904, SEEK_SET) .................. = 18014715904
[7022] read(78, "04n 8 X 04n 8 Y 04n 8 g b 13aef0".., 16384) = 16384
[7022] lseek(78, 18014699520, SEEK_SET) .................. = 18014699520
[7022] read(78, "04n 8 P 04n 8 Q 04n 8 _ b 13aef0".., 16384) = 16384
[7022] lseek(78, 18014797824, SEEK_SET) .................. = 18014797824
[7022] read(78, "04n 8 8004n 8 8104n 8 W b 13aef0".., 16384) = 16384
[7022] lseek(78, 18014814208, SEEK_SET) .................. = 18014814208
[7022] read(78, "04n 8 8804n 8 8904n 8 87b 13aef0".., 16384) = 16384
[7022] select(0, NULL, NULL, NULL, 0xc0000000856a4190) ... = 0

David

[David Child_1]

Just an update for those who are interested. While the archive was running slow one of the DBAs ran a manual query to see how it would run. Not only did it run fast, but the poorly performing archive jumped from 1-2 I/Os per sec to ~300 I/O per sec. Using this workaround we were able to 'jump-start' the archive if it bogged down. After discussing this with some DBAs one of them recalled seeing this before on another system. In that case they upgraded Sybase from 11.9.3 to 12.5 and the problem went away. This current database is also at 11.9.3.

The tool they are using to archive is called 'sqsh'.