Skip to content

Debugging flows #340

Open
Open

Description

@guyisra

We have rendered the world (partially successfully), yet we seem to sometimes missing tiles (from zoom 13 upwards)

Besides the seed all config, is there another config zoom limitation that could stop the processing (or enqueuing) of tiles? Using tileserver to server directly from the DB I see that the tiles do exist in the DB, so either they weren't enqueued (but since the high zoom levels are processed from the rawr tiles it's harder to debug) or something else happened.

  1. Is there a config to limit zoom level processing?
  2. What is the recommended flow to debug the processing of high zoom tiles?

Activity

  1. zerebubuth commented on Jul 3, 2018

    @zerebubuth
    Member

    The seed command will make a job for every tile between the zoom levels configured, inclusive of the start and end zooms.

    I've seen jobs can fail for a wide variety of reasons, so no obvious culprit comes to mind. Some of the ones I've seen, off the top of my head; out of memory, too many rate-limit (429) responses from S3, having the wrong bucket permissions, TTL expired, "Docker didn't start quickly enough", and - of course - tilequeue and vector-datasource software bugs.

    Are you able to get the log files from the instance / container running the job? If not, and the failure is reproducible (e.g: putting a single tile coordinate in a file and feeding it to the "top tiles" seed config), then you could try running it locally and seeing what the error is?

    Hope that helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions