I have read that Livelock is special case of Resource Starvation here. I have also read that in Livelock Process are not in a waiting state here.
A/c to Galvin Book on OS, Starvation is Process waiting indefinitely, be it for acquiring resource or be it for getting scheduled by scheduler or be it in queue of Semaphore etc.
My question:
Is it possible for the Processes to suffer from Livelock without Starvation in any case?
If someone is willing to say no and have explanations for it, I would request you to once go through the scheme mentioned here. For that scheme I don't think that there is starvation but obviously there is livelock. I have explained my thoughts on the cs.se link mentioned below.
I have already asked my specific doubts on the cs.se here, but don't have any response yet.
Related
I started learning OS and understanding it's concept but can somebody explain as to why is it bad for an operating system to have a deadlock system?
According to what I gathered it's not bad for a system to have a deadlock prevention system, but if an OS has a deadlock prevention system then it may slow down the system as whenever a process or thread will request for a resource then first the system will check if there's any possibility to have a deadlock situation and also such system might be expensive. So, that's why most systems ignore deadlock.
The question is about Play framework specifically although concept is generic.
Quoting from:
https://www.playframework.com/documentation/2.6.18/ScalaAsync
The web client will be blocked while waiting for the response, but
nothing will be blocked on the server, and server resources can be
used to serve other clients.
Using a Future is only half of the picture though! If you are calling
out to a blocking API such as JDBC, then you still will need to have
your ExecutionStage run with a different executor, to move it off
Play’s rendering thread poo
I understand the part that the original web application threads will be freed however another thread will still be needed to actually perform the cpu intensive action and then calculate the result, which will be propagated to the client (which is blocked meanwhile).
How is better than synchronously performing the execution in the play's action code? We would have to increase the number of threads (as the blocking request will consume threads), however total number of active threads on the server will remain the same.
Can someone also throw light on how does Play track the blocked client thread and returns the response in the non-blocking action scenario?
Using different thread pools for rendering and long-running operations is desirable because that way the long-running operations can use all of the threads in their pool without blocking rendering.
Imagine this situation:
10 clients make requests for resources that require long-running operations.
Then a client tries to access a resource that doesn't.
Here are two ways that this could be handled:
You have a pool with 10 threads used for everything. These fill up doing your long-running operations, and the other client — who has a simpler request! — has to wait for one of the long-running calls to finish.
You have two thread pools, one with 5 threads used for rendering and another with 5 threads used for long-running operations. The rendering threads quickly give the long-running operations work to the other pool, freeing them to respond to the eleventh client's request.
The second situation is definitely better, but I would like to point out another reason for having multiple thread pools: sometimes different operations require different kinds of system resources. For example, rendering might be CPU-bound, while database calls might be mostly network-bound, or CPU-bound but done on a different machine (the database server). If you use the same thread pool for both, the threads might get busy waiting for network calls to finish while the CPU sits mostly idle, even if you have several CPU-bound tasks queued. That would be an inefficient use of resources, so you should have different thread pools for different kinds of tasks.
Requests that our app needs to serve exhibit great variance (unknown in advance) of processing latencies (from few seconds to hours).
We'd like to use kubernetes autoscaling capabilities but it is not clear how to deal with random pod termination policy during downscaling (as it comes at odds with our desire to not terminate long running requests being processed).
Wondering if anybody else has seen similar situations? what solutions did you come up with?
One of the things you can do, is to build into your app support for termination handling and set a rather long termination grace period. You can find a nice explanation of this topic in https://pracucci.com/graceful-shutdown-of-kubernetes-pods.html
This does not completely prevent you from killing long term connections. To be honest, nothing will. Yet it does significantly limit the impact of events like scaling on this type of workloads.
I am trying to profile an Akka app that is constantly at or near 100% CPU usage. I took a CPU sample using visualvm. The sample indicates that there are 2 threads that make up 98.9% of CPU usage. 79% of the cpu time was spent on a method called sun.misc.Unsafe. Other answers on SO say that it just means that a thread is waiting but in the native implementation layer (outside of the jvm).
In questions similar to mine, people have been told to look elsewhere without being given specifics. Where should I look to figure out what's causing the cpu spike?
The application is a server that primarily uses Akka IO to listen for TCP socket connections.
Without seeing any of the source code, or even knowing what IO channel you are talking about (sockets, files, etc), there is very little insight that anyone here can give you.
I do have some rather general suggestions though.
First, you should be using reactive techniques and reactive IO in your application. This issue could be occurring because you are polling the status of some resource in a tight loop, or using a blocking call when you should be using a reactive one. This tends to be an anti-pattern and a performance drain exactly because you can spend CPU cycles doing nothing but "actively waiting". I recommend double checking for:
resource polling
blocking calls
system calls
disk flushes
waiting on a Future when it would be appropriate to map it instead
Second, you should NOT be using Mutexes or other thread synchronization in your application. If so, then you might be suffering from a live-lock. Unlike dead-locks, live-locks manifest with symptoms like 100% CPU usage as threads constantly lock and unlock concurrency primitives in an attempt to "catch them all". Wikipedia has a nice technical description of what a live lock looks like. With Akka in place you shouldn't have any need to use Mutexes or any thread synchronization primitives. If you are then you probably need to re-design your application.
Third, you should be throttling IO (as well as error handling like reconnection attempts). This issue could be occurring because your system lacks effective throttling. Often with data channels we leave their bandwidth unconstrained. However this can become an issue when that channel reaches 100% saturation and begins to steal resources from other parts of the system. This can happen, for example, if you are moving large files around without a reasonable limit.
Alternatively, you also need to throttle connection retries when you encounter any errors, rather than retrying immediately. Lots of systems will attempt to reconnect to a server if they lose their connection. While normally desirable, this can lead to problematic behavior if you use a naive reconnection strategy. For example, imagine a network client that was written this way:
class MyClient extends Client {
... other code...
def onDisconnect() = {
reconnect()
}
}
Every time the Client disconnects for ANY reason it will attempt to reconnect. You can see how this would cause a tight loop between the error handling code and the Client if the Wifi cut-out or a network cable was unplugged.
Fourth, your application should have well defined data sources and sinks. Your issue could be caused by a "data loop", that is some set of Akka actors that are just sending messages to the next actor in the chain, with the last actor sending the message back to the first actor in the chain. Make sure you have a clear and definite way for messages to enter and exit your system.
Fifth, use appropriate profiling and instrumentation for your application. Instrument your application using Kamon or Coda Hale's Metrics library.
Finding an appropriate profiler will be more difficult, since we as a community have far to go to develop mature tools for reactive applications. Personally I have found visualvm useful, but not always overwhelmingly helpful for detecting code paths that are CPU bound. The issue is that sampling profilers are only able to collect data when the JVM reaches a safepoint. This has the potential to bias certain code paths. The fix is to use a profiler that supports AsyncGetStackTrace.
Best of luck! And please add more context if you can.
May be this question is not fitting into the stackoverflow FAQ
The reason I am asking this question is that a senior developer came in to the team and started saying that we should move our code to a custom threadpool manager instead of relying on celery to do asynchronous multiprocessing
We love celery because it is so easy. But the argument seems valid, mostly because we do not want to give up on efficiency.
Is it true that since celery uses multiple processes instead of multiple threads, we are loosing on efficiency?
Firstly, look at doc:
On Unix the processes pool will fork, so that child processes start
with the same memory as the parent process.
Secondly, Celery can more. It may use microthreads. Read page about how does it
Finally, we can say that microthreads more efficiency than threads, and threads more efficiency processes. But you must remember it depends also from hardware configuration