Massive inserts cause 100% processor usage - w/o active process in db

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Create SQL with multiple immediate inserts
2. insert into xxx values (yyy, zzz)
3. Execute all inserts
4. Check active db processes. There is none
5. Check processor usage 1 processor is 100% used.

What is the expected output? What do you see instead?

No processor usage, immediate response in log.

What version of the product are you using? On what operating system?

Trunk.92 version. I believe it does not depends on OS used.

Please provide any additional information below.

Test SQL statements is attached.

Original issue reported on code.google.com by rusla...@gmail.com on 31 Jul 2009 at 8:00

Attachments:

• massive_inserts.sql

[GoogleCodeExporter]

I believe it is somehow related to recent changes to provide buffering of log 
window.
But I am unable to find discussion or issue which desribe changes.

Original comment by rusla...@gmail.com on 31 Jul 2009 at 8:05

[GoogleCodeExporter]

I detect that 90% taking thread in msvcr71.dll (screenshot attached)
Any ideas ?

Original comment by daggett....@gmail.com on 2 Aug 2009 at 11:13

• Changed state: Accepted

Attachments:

• aseisql-cpu.gif

[GoogleCodeExporter]

there was a discussion about this feature 
http://groups.google.com/group/aseisql/browse_thread/thread/eb3f90bb816033d1

and commit:
just a patch http://code.google.com/p/aseisql/source/detail?r=35
--
can you confirm that in version 2007-11-19 this bug does not exists?

Original comment by daggett....@gmail.com on 2 Aug 2009 at 5:47

• Changed state: Feedback

[GoogleCodeExporter]

I have seen this problem numerous time in 2007-11-19

Original comment by pierre.s...@gmail.com on 11 Aug 2009 at 6:37

[GoogleCodeExporter]

i did some tests in a simple PowerBuiler application.
now i can confirm that it is an issue of PowerBuilder itself :(
the simple thread in PB application cause 100% cpu load in microsoft 
"msvcr71.dll"
library.
--
I'll post the issue to sybase forums...
another solution could be not to use PB threads (sharedobjects), but to 
implement it
in C library (syb_exec.dll).
--
For now, I postpone this issue.

Original comment by daggett....@gmail.com on 17 Aug 2009 at 7:53

• Changed state: Postpone
• Added labels: Performance

[GoogleCodeExporter]

after additional set of tests, i found that those 100% of CPU produced mainly 
by 
"go" parsing code, and sql execution...
new tests required.
possible cases:
 - "go" parsing code
 - sybase ctlib 
 - ?

Original comment by daggett....@gmail.com on 26 Aug 2009 at 5:40

• Added labels: Priority-Low
• Removed labels: Priority-Medium