Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High CPU when subscribing to parameter_events with Discovery Server #4364

Open
1 task done
outrider-jhulas opened this issue Feb 8, 2024 · 0 comments
Open
1 task done
Labels
triage Issue pending classification

Comments

@outrider-jhulas
Copy link

outrider-jhulas commented Feb 8, 2024

Is there an already existing issue for this?

  • I have searched the existing issues

Expected behavior

Subscribing to the /parameter_events topic while using Discovery server shouldn't cause the CPU of the subscriber process to go 100%.

Current behavior

When subscribing to the /parameter_events topic in one node and launching a composable node container with few even very simple composable nodes (5-10), there is a significant spike of the CPU usage from around 0% to 100%.

  • The nodes need to be launched with the discovery server present, to observer the CPU spike
  • No significant spike when publishing from the cli
  • Launching the nodes in multiple separate processes doesn't cause the issue
  • If the simple node has the start_parameter_event_publisher(false) and start_parameter_services(false) options set, then there is no CPU spike

Steps to reproduce

  1. Create a node with a subscriber to the /parameter_events
SimpleMonitor::SimpleMonitor(const rclcpp::NodeOptions & options)
: Node("simple_monitor", options)
  , parameter_event_subscription_(
    this->create_subscription<rcl_interfaces::msg::ParameterEvent>(
      "/parameter_events", rclcpp::QoS(1),
      [](const rcl_interfaces::msg::ParameterEvent::SharedPtr) {
        // Do nothing
      }))
{}
  1. Create a simple node with a single pub or sub, of any topic.
  2. Create a launch file to launch multiple nodes in a container, eg:
def generate_launch_description():
    # Launch configurations
    node_number = LaunchConfiguration('node_number')

    # Arguments
    node_number_cmd = DeclareLaunchArgument(
        'node_number',
        default_value='1',
        description='repeats.')

    def container_launch(context):
        """Launch the node."""

        nodes = []
        for i in range(int(node_number.perform(context))):
            nodes.append(ComposableNode(
                package=PACKAGE,
                plugin='simple_node::SimpleNode',
                name='simple_node_' + str(i),
            ))
        container_cmd = ComposableNodeContainer(
            name='my_node_container',
            package='rclcpp_components',
            executable='component_container',
            composable_node_descriptions=nodes,
            output='screen')

        return container_cmd

    ld = LaunchDescription()
    ld.add_action(node_number_cmd)
    ld.add_action(OpaqueFunction(function=container_launch))
    return ld
  1. Launch the subscriber node and then the container.
  2. Observe the CPU spike

Fast DDS version/commit

Fast DDS: ros-humble-fastrtps: 2.6.6-1jammy.20230919.195605
Discovery server: fastdds-tools: 2.5.0+ds-3

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Default configuration, UDPv4 & SHM

Additional context

Ubuntu 22.04
ROS2 Humble
The discovery server and the ros2 application running in two separate docker containers

XML configuration file

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Copyright 2023 Outrider Technologies, Inc.  CONFIDENTIAL. -->
<dds>
    <profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
        <participant profile_name="super_client_profile" is_default_profile="true">
            <rtps>
                <builtin>
                    <discovery_config>
                        <discoveryProtocol>SUPER_CLIENT</discoveryProtocol>
                        <discoveryServersList>
                            <RemoteServer prefix="44.53.00.5f.45.50.52.4f.53.49.4d.41">
                                <metatrafficUnicastLocatorList>
                                    <locator>
                                        <udpv4>
                                            <address>127.0.0.1</address>
                                            <port>11812</port>
                                        </udpv4>
                                    </locator>
                                </metatrafficUnicastLocatorList>
                            </RemoteServer>
                        </discoveryServersList>
                    </discovery_config>
                </builtin>
            </rtps>
        </participant>
    </profiles>
</dds>

Relevant log output

No response

Network traffic capture

No response

@outrider-jhulas outrider-jhulas added the triage Issue pending classification label Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Issue pending classification
Projects
None yet
Development

No branches or pull requests

1 participant