From distcc's documentation I understand that localslots_cpp can limit the concurrency of preprocessing. But the setting of localslots_cpp doesn't work when called via ccache.
Related
If I run the following command, I get a "virtual microphone" that's hooked up to a sink called "MicOutput". If I send data to "MicOutput", that data is then sent to the virtual microphone.
pactl load-module module-null-sink sink_name=MicOutput sink_properties=device.description="MicOutput"
pacmd load-module module-virtual-source source_name=VirtualMic master=MicOutput.monitor
I can get similar behavior if I replace the second line with:
pactl load-module module-remap-source source_name=Remap-Source master=MicOutput.monitor
The main difference I see is that the latency is lower.
But what's the difference? When would I want to use one, or the other?
My Research so far
I see these two files:
https://fossies.org/linux/pulseaudio/src/modules/module-remap-source.c (added in 2013)
https://fossies.org/linux/pulseaudio/src/modules/module-virtual-source.c (added in 2010)
Perhaps if I looked at the code hard enough I'd understand the answer. I wonder if someone happens to know the answer though?
module-virtual-source is not typically used. It's an example of how a "filter source" should be implemented.
Module-remap-source has much less overhead
Source: I asked the PulseAudio team. https://lists.freedesktop.org/archives/pulseaudio-discuss/2022-April/032260.html
I am trying to debug an issue related to keep-alives/connection resets and found that tomcat documentation says:
socket.soKeepAlive:
(bool)Boolean value for the socket's keep alive setting (SO_KEEPALIVE). JVM default used > if not set.
This is not set by the application I am debugging. Is there a way to figure out the default the jvm is using? (For instance by inspecting a system property?)
I cannot test out the behavior by inspecting the actual keep alive behavior since I don't have access to the VM.
Answering on my own based on more research and experimentation.
Default value of socket.soKeepAlive: From the JVM docs for SocketOptions.SO_KEEPALIVE:
The initial value of this socket option is FALSE. The socket option may be enabled or disabled at any time.
Also to note:
When the SO_KEEPALIVE option is enabled the operating system may use a keep-alive mechanism to periodically probe the other end of a connection
From what I understood, this would mean tomcat would not probe clients to check if an established connection is active by default
Default Value of keepAliveTimeout: The default value is to use the value that has been set for the connectionTimeout attribute
In my case this was not being reflected. connectionTimeout was set to 10 seconds, but still tomcat responses had keep alive headers set to only 5 seconds.
However, I found that the application authors also set an attribute called socket.soTimeout to 5 seconds which tomcat describes as:
This is equivalent to standard attribute connectionTimeout.
I found that when both conncetionTimeout and socket.soTimeout are set, socket.soTimeout takes precedence since changing the socket.soTimeout value caused the values returned by keep alive headers to change accordingly.
The C-driver for Postgres prints NOTICE messages to STD output.
How it could be disabled? I'm using STD output for logs and these unexpected messages breaks log parsing.
There's client_min_messages parameter that controls the level of messages, but I need to completely disable it, so even errors shouldn't be printed.
Is there a way to do that? I'm using PostgreSQL 13.2
You could execute
SET client_min_messages = error;
to disable as many messages as possible. Note, however, that
INFO level messages are always sent to the client.
as the documentation says.
But it would be way better to set up a notice handling function as detailed in the documentation.
Is it possible to rotate a logfile immediately in webMethods - by calling a special method or whatever. I do not want to use third-party software.
Further explanation
I need this rotation for both. The default logfile(s) (e.g. server.log) and custom logfiles.
By default webMethods logs (all components such IS, MWS, Optimize etc) rotate every 24h on midnight. You can change that interval by modifying an extended property.
For IntegrationServer 9.6 and lower it is watt.server.logRotateInterval (in milliseconds).
Please note: The watt.server.logRotateInterval parameter was removed from Integration Server after
8.2 SP2. When it was reintroduced for the following fixes, the scope of the parameter changed so that it affected only the stats.log:
IS_9.0_SP1_Core_Fix6
IS_9.5_SP1_Core_Fix3
IS_9.6_Core_Fix2
Starting with Integration Server 9.7, this server configuration parameter has been renamed watt.server.statsLogRotateInterval (in minutes instead of milliseconds), but affects only stats.log file as well.
So I think there is no way to change the log rotate interval. For compressing the old log files I think the best solution would be to write a service that does that and used that service to create a scheduled task (executed daily after midnight).
I am using xen hypervisor. I am trying to get the IO count of the VMs running on top of the xen hypervisor. Can someone suggest me some way or tool to get the IO count ? I tried using xenmon and virt-top. Virt-top doesnt give any value and xenmon always shows 0. Any suggestions to get the number of read or write calls made by a VM or the read and write(Block IO) bandwidth of a particular VM. Thanks !
Regards,
Sethu
You can read this directly from sysfs on most systems. You want to open the following directory:
/sys/devices/xen-backend
And look for directories starting with vbd-
The nomenclature is:
vbd-{domain_id}-{vbd_id}/statistics
Inside, you'll find what you need, which is:
br_req - Number of block read requests
oo_req - Number of 'out of' requests (no room left in list to service any given request)
rd_req - Number of read requests
rd_sect - Number of sectors read
wr_sect - Number of sectors written
The br_req will be an aggregate count of things like write barriers, aborts, etc.
Note, for this to work, The kernel has to be told to export Xen attributes via sysfs, but most Xen packages have this enabled. Additionally, the location in sysfs might be different with earlier versions of Xen.
have you tried xentop?
There is also bwm-ng (check your distro). It shows block utilization per disk (real/virtual). If you know the name of the virtual disk attached to the VM, then you can use bwm-ng to get those stats.