There are lots of solutions/comments here, none of which address the fundamental question. What entity is too large? We had the same issue and we eventually identified that the entity in error was a viewstate object in the ASPX page. Just making the size of the maxBufferPoolSize, maxBufferSize and maxReceivedMessageSize to be enormously large is not really the correct solution. It will work but you're only masking the problem and it'll occur at some point in the future.
ViewState
A web application is stateless. That means that a new instance of a page is created every time when we make a request to the server to get the page and after the round trip our page has been lost immediately. It only happens because of one server, all the controls of the Web Page is created and after the round trip the server destroys all the instances. So to retain the values of the controls we use state management techniques. View State is the method to preserve the Value of the Page and Controls between round trips. It is a Page-Level State Management technique. View State is turned on by default and normally serializes the data in every control on the page regardless of whether it is actually used during a post-back.
Solution
Our webpage was displaying a gridview of records which by user request gave access to every record in the underlying data query view. As records were added to the tables outside of this view, the Gridview Dataset grew to be too large for the ASPX page to save and recall the viewstate object. Our solution was to understand the business reasons why the whole of the dataset was required and as it turned out generally it was only the last 7 days worth of data that was required, any further back in time was catered for by a standing report. Once this was understood then we simply amended the page query to limit to the last 7 days of data, promulgate the change and inform users. Problem fixed.