Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #4210] ido2db gradually consumes more and more CPU time with time #1285

Closed
icinga-migration opened this issue May 25, 2013 · 8 comments
Milestone

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/4210

Created by crfriend on 2013-05-25 20:13:13 +00:00

Assignee: crfriend
Status: Resolved (closed on 2013-06-03 18:55:38 +00:00)
Target Version: 1.9.2
Last Update: 2014-12-08 14:38:07 +00:00 (in Redmine)

Icinga Version: 1.10.0
OS Version: any

These are early results, but I am seeing my ido2db process consuming more and more CPU time on a 440 MHz SPARC processor as the runtime increases. Along with this, I am seeing a lot of BEGIN/COMMIT cycles with no transaction data bracketed by same.

At this time I am leaning towards a failure to check for actual data at line 1538 in ido2db.c where ido2db_check_for_client_input does not indicate whether anything was available or not.

Film, as they say, at eleven and, likely a patch.

Attachments

Changesets

2013-06-22 15:53:13 +00:00 by (unknown) f841c16

update Changelog

refs #4049
refs #4210

Relations:

@icinga-migration
Copy link
Author

Updated by crfriend on 2013-05-26 15:14:25 +00:00

It's also leaking memory -- it's gone from about 5728k to 9458k in about an hour and a half...

@icinga-migration
Copy link
Author

Updated by crfriend on 2013-05-27 02:14:20 +00:00

  • File added 0001-Issue-4210-partial-memory-leak-in-ido2db.patch

Test patch is operational in my lab with no memory-usage creep in two hours' time.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-05-27 07:34:03 +00:00

  • Target Version set to 1.9.2

@icinga-migration
Copy link
Author

Updated by crfriend on 2013-05-27 15:38:22 +00:00

  • Status changed from New to Feedback
  • Assigned to set to crfriend

The memory leak was solved by the attached patch. The repeated BEGIN/COMMIT issue is primarily the result of a NEBTYPE_TIMEDEVENT_SLEEP type in the datastream which the dbhandler code dismisses with an IDO_OK without a database access, and this is a separate issue altogether.

Should I split this issue into two pieces (one of which is fixed, and the other will likely have ramifications in core as it may affect some of the include files) or should I ignore the empty BEGIN/COMMIT cycles?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-05-27 15:42:20 +00:00

please create a branch on the fix/.* tree, according to the dev guidelines for git flow, just as "fix/topicname-issueid". and yes, split issues by their topic - some might get merged into releases, some are kept for dev in 'next' only.

@icinga-migration
Copy link
Author

Updated by crfriend on 2013-05-27 16:18:09 +00:00

dnsmichi wrote:

please create a branch on the fix/.* tree [...]

In progress.

and yes, split issues by their topic - some might get merged into releases, some are kept for dev in 'next' only.

OK, I will create a new one for the empty BEGIN/COMMIT transactions and retain #4210 as the memory leak.

Thanks.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-06-03 18:55:38 +00:00

  • Status changed from Feedback to Resolved
  • Done % changed from 0 to 100

fixed branch was merged into #4049 where more bugfixes on socket queue / transactions live.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-12-08 14:38:07 +00:00

  • Project changed from 18 to Core, Classic UI, IDOUtils
  • Category changed from 79 to IDOUtils
  • Icinga Version changed from 1 to 1
  • OS Version set to any

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant