In solaris, orphan process is put to sleep mode and does not consume any CPU resources. In Linux, orphan process is kept in running state consuming all CPU and Ram resources. Is it the case? Is there a difference on how these operating systems will handle orphan processes?
The route cause of asking this question is, we were having one application on solaris , we migrated that on RHEL 6. On solaris, that application was running perfectly fine even if after orphan processes generated. After migrated it on Linux, it is started freezing, giving performance issues, consuming more RAM and CPU utilisation is 99%. It did not happened on solaris.
You state in your post that Solaris systems and Linux systems behave completely differently when a parent process terminates without waiting for its children to terminate and then ask if they behave differently when a parent process terminates without waiting for its children to terminate??? Although I find it hard to believe that many of the differences that you stated as facts are true; if you believe that those facts are true, I do not understand why you are asking the question.
Is this a homework assignment?
What code are you running that exhibits the differences you are seeing on Solaris systems and Linux systems?
What Solaris release(s) are you using?
What Linux distribution(s) are you using? Which version(s) of those Linux distribution(s) are you using?
Thanks for your response.
In Linux (RHEL 6), when a process becomes orphan, it consumes all the CPU resources. No resources are left for the application to run.
In Solaris (10), when a process becomes orphan, we do not see any load on the server. We have no issues to run the application.
If possible, I would like to understand why the same orphan process consumes more resources in Linux and not in solaris.
Dispite different implementations, Solaris 10 and RHEL 6 should behave the same in principal:
if a parent process terminates, the child process is hooked to pid 1 (init). It depends on the client process' code (application) what happens then.
So you should examine your application with tools like strace .
1 Like
We have applied strace command, found some error on recv() system call, that is failing returning -1 , error "temporarily resources are unavailable "
Well, that's a start, what were they reading from?
The same application in solaris is migrated to Linux. We have not done anything more. except this migration. Then also same application performance is not good in Linux. It was good in solaris. I would like to know what is the reason.
You seem to be saying that you have poorly written code that runs quickly on Solaris 10 systems consuming huge amounts of CPU cycles while not checking for error returns on sockets and that the same code when ported to a Red Hat version 6 Linux distribution runs slow and stops when the same networking error occurs.
Without seeing the Solaris 10 code you're using and the RHEL 6 port of that code it is very hard to guess at what might be causing the differences in behavior you have described. My crystal ball isn't working well enough tonight to even hazard a guess.
1 Like
If the application is made up for RHEL 3 and RHEL 4 , and if we will deploy it on RHEL 6, then what will be side effects? Will it affect on performance of application?
It might run faster. It might run slower. It might not run at all. It might run perfectly for a while and crash hours later. And, of course, it could also depend on what data the code encounters while it is running. If you don't show us the code, there is no way to know!
1 Like
Processes don't become orphans for no reasons: you must have done something (i.e. terminating the parent process without waiting for - and processing properly the exit code of - the client) and, since you seem to know that already, i wonder why you ask for the consequences of this instead of correcting it.
I mean: sometimes parking at where it is forbidden results in your vehicle towed, sometimes not (like poor implementation is punished in one OS and not punished in another). But even it not resulting in a ticket doesn't make the practice any more legal, you just didn't get punished for what you did wrong immediately. You perhaps are still an obstacle to other traffic, which is why the parking was forbidden there in the first place.
So, instead of asking us (as i perceive it) how can i write bug-ridden programs so that the bugs won't show you should ask yourself how to get rid of the bugs - and then act accordingly.
I hope this helps.
bakunin
1 Like