I assume the load is mostly related to IO!?

the first thing would probably be to do some profiling, then we know what is going on.

Take a look at rosbag/Commandline - record, have you investigated the effect of buffsize and chunksize?

Additionaly - but without profiling this is really all speculative: network topology and other system characteristics are going to influence everything, so it might be good to describe that a bit.

Is the increased load only in the rosbag process? I've found that recording high-throughput topics with no other subscribers can add significant serialization overhead to the publisher (which was previously idle).

@gvdhoorn, I played with buff- & chunk-size, but this did not get big improvements. I only did some system profiling (iostat, netstat, etc.) but still need to profile the record node and others.

@Ed Venator, yep, this is true, I see other nodes' CPU rising when turning on recording.

@Ed Venator, I guess besides reducing messages sizes (which I have done as much as possible), reducing frequencies and not recording everything, there is not much to do to improve performance?

There's probably not much you can do. You could use topic_tools/throttle to reduce the rate of the topics going into the record node, but there's no way to completely isolate the effects of bagging.

Just to get an idea: if load is increased because rosbag introduces additional subscribers then it might be interesting to know what sort of nrs of nodes we're talking about here. 10, 100? rosbag record -a obviously records everything, so that could result in quite some additional subscriptions.

Do you have any nodelets, or is everything only nodes? I don't know what the status is, but if you have nodelets then osrf/nodelet_rosbag could be interesting.

I see other nodes' CPU rising when turning on recording.

that is somewhat expected, but I would expect that transferring one additional float to a single additional subscriber should not lead to 5 times the load on the system. Can you say a bit more about topology and architecture?

@gvdhoorn: 10 nodes, which have increased CPU load when bagging is on. I see CPU rising from 5% to 10%. Including a record node (does "record -a") running at ~ 100% CPU could explain part of the load increase. probably IO adds to the load as well, which gives us the 4x load increase

@gvdhoorn: Topology is very simple: all ROS nodes run on a 6-core multiprocessor. once bagging is turned on, a recorder ROS node running on the same processor listens to all topics and writes a bag file to disk. Each message is comprised of float32 values. we send roughly 10 floats per message.