What can cause a hosted feature service to be large?

[DeniseVachon]

I have a hosted feature service that is reported as being quite large (3.3GB). The service has 15 features in it (line and polygon). Syncing and editing are not enabled. None of the layers are optimized for drawing. The ground area is relatively small (a few neighborhoods).

What could cause a service like this to be so large?

[jcarlson]

I'd check

• number / size of the fields
• vertex count on your features
• attachments

Has the layer by chance been overwritten in the past? Sometimes the size attribute hangs on from the initial publishing of a layer, and does not reflect the current state of the data.

For instance, I published an empty table, and our Portal says it takes up no storage at all. Since that initial publish, the service has added tens of thousands of records across 7 tables, with multiple attachments on many of them. The only way to get a true sense of the size of our service is to remote into the machine and actually look at the size of the folders where the data is being stored.

[jcarlson]

Oh and the precision on the location data, too. It would take a LOT of decimal places to add up to multiple gigs, but it's still worth checking.

[DeniseVachon]

Thanks Josh!

The number of fields is small and there are no attachments, but there are 6000+ vertices. I'm not sure if that is a lot. Do you know?

It seems like it might not be a lot based on the fact that I have a hosted feature service point layer that contains hundreds of thousands of points and takes up less space. But maybe point features are more efficient to store than polygon vertices.

The layer was published yesterday and has not been overwritten.

[jcarlson]

Whether or not it's a lot depends on the feature, but I don't see it being the cause for such a large size being reported.

Was the layer published from a larger layer with a definition query applied to it?

[DeniseVachon]

Yes, I believe it was published from a larger layer with a definition query.

[jcarlson]

Someone else posted about this. Evidently the size of the entire input is recorded, regardless of how much data actually lands on the Portal.

Is this AGOL or Enterprise? Do you have direct access to the machine hosting the layer?

The size being reported on the Item Details page is not reliable, and does not update as the layer is used, so the only way to really see how big a layer is (as far as I know) is to actually root around in the server machine.

[DeniseVachon]

Good to know! Thank you!

This layer is hosted on ArcGIS Online, hence my desire to understand why it is labelled as large. 😄 It is eating up credits.

Maybe I'll reach out to Esri Tech Support to see if they can shed light on the actual size of this feature service.

[jcarlson]

Is the service definition being stored as a separate item? Try deleting that and see if your credit usage drops. The SD actually would be that large, but I bet the size of the service itself is tiny.

[DeniseVachon · Accepted solution]

I finally figured this out. The large size reported was due to a definition query that we had on one of the features in the original ArcGIS Pro map document. I found this in the depths of AGOL doc:

"If the layers in the ArcMap or ArcGIS Pro map have definition queries applied to them, ArcGIS applies the definition queries to the published hosted feature layer. However, all data is uploaded to ArcGIS Online. If you want only a subset of the data to be published to and stored in ArcGIS Online, you must export the subset of the data to another feature class and publish that." 

Publish hosted feature layers—ArcGIS Online Help | Documentation