Is there a way to run a background thread in solr that would run a systemd watchdog (ie sd_notify) to make systemd aware of solr's status?
This library seems like a reasonable way to implement sd_notify in java.
I can't find much information about a way to hook into SOLR's startup to kick off a background thread that would handle the sd_notify calls.
Related
For some context, I'm profiling the execution of Memcached, and I would like to monitor dTLB misses during the execution of a specific function. Assuming that Memcached spawns multiple threads, each thread could potentially be executing the function in parallel. One particular solution I discovered, Perf features toggle events (Using perf probe to monitor performance stats during a particular function), should let me achieve this by setting probes on function entry and exit and toggling the event counter on/off on each probe respectively.
My question is:
(a) From my understanding, perf toggle events was included as part of a branch to Linux kernel 3.x. Has this been incorporated in recent LTS releases of Linux kernel 4.x? If not, are there any other alternatives?
(b) Another workaround I found is described here: performance monitoring for subset of process execution. However I'm not too sure if this will work correctly for the problem at hand. I'm concerned since Memcached is multi-threaded, having each thread spawn a new child process may cause too much overhead.
Any suggestions?
I could only find the implementation of the toggle events feature in the /perf/core_toggle repo, which is maintained by the developer of the feature. You can probably compile that code and play with the feature yourself. You can find examples on how to use it here. However, I don't think it has been accepted yet in the main Linux repo for any version of the kernel.
If you want to measure the number of one or more events, then there are alternatives that are easy to use, but require adding a few lines of code to your codebase. You can programmatically use the perf interface or other third-party tools that offer such APIs such as PAPI and LIKWID.
I'm write a time-critical application in C on an embedded computer and need to change the scheduling policy of the process. Using pthread_setscheduler with SCHED_RR leads to sufficient results for me. But now the application needs root-rights. But giving root-rights to the application is not very nice. Is there any possibility to set round-robin without the need of root-rights?
Or there are a more elegant solution?
Another approach with setcap
sudo setcap cap_sys_nice+ep my_application
leads to problems while loading some own shared libraries which are placed in several folders.
I have been looking at various ways to implement a timer or alarm that will executes a cleanup function for a program in an embedded system with minimal resources.
Essentially, I'd like the function to be executed when the system is under minimal load, minimal network activity and/or when a period of time has been reached.
I think multi-threading a timer isn't a viable option and probably overkill and a timer executing when the system is busy.. is probably not a good option either.
Ideas anyone?
EDIT:
Running OpenWRT and busybox
I ended up using variables and a timer to solve my issues. The timer executes, but based off of the variables - I either execute the code.. or not.
I am using C language and Linux as my programming platform.
I am developing a user-space application that runs in a background, like a daemon. And my problem is, I want another user-space application to communicate with this daemon.
I know that I have to use Interprocess Communication method but I don't know what is the correct implementation.
But using IPC in my communication implementation is my other option. Actually I just want to change the attribute of my daemon by using another application. Please see below a senario:
My daemon runs in a background.
Then some application will control the properties of a daemon, like sleeping delay time.
My first option is by accessing a file with the values of the properties. So that my deamon will poll that values. While the other application will change that values.
I am not sure the efficiency of my options. Please advice.
THanks.
Updating the config file and sending a signal to cause re-read is a standard practise, cheap and easy.
You're looking for D-Bus. Store the initial values in a file, then listen over D-Bus for requests to change it.
Unix domain sockets are a simple IPC method.
If I were you, I'd forego IPC completely and instead have the daemon monitor a config file for changes. IPC is only really needed if you're going to be sending thousands of messages per second and the overhead would get intolerable.
inotify is an option for file monitoring.
I'd make the daemon listen on a pipe/fifo if it's simple enough that you only need to read a couple of bytes fed in from another program. Otherwise a local domain socket is nice to run a simple protocol over.
I need to add timers support in an application based on I/O Completion Ports (IOCP). I would like to avoid the use of a specific thread to manage timers.
On Linux, you can create a timer that delivers expiration notifications via a file descriptor (see timerfd.h man), so it's great to use it for example with epoll if your application is based on epoll.
On Windows, you can use "waitable timers" with an asynchronous procedure call (ACP) (see http://msdn.microsoft.com/en-us/library/ms686898(v=VS.85).aspx)
If you are interested, kqueue (BSD, Mac OS) supports timers by default (see EVFILT_TIMER).
With I/O Completion Ports, we have to use objets that support overlapped I/O. So, is there such a timer for IOCP ?
Best regards,
Cédrics
As far as I know there are no timers that generate a IOCP completion when they expire.
You could try the Windows timer queue; CreateTimerQueueTimer.
I ended up writing my own timer queue which does use an extra thread to run the timers, so it's probably no good for you: See here for a series of articles where I implement the queue with TDD and full unit tests. I'm in the process of implementing a higher performance TimerWheel with the same interface, but again that will use an external thread to manage the timers.
You could use waitable timers and queue a custom packet to the completion port using "PostQueuedCompletionStatus". But remember that if there are multiple worker threads only one of the thread will be notified.