Getting a session is very slow

This problem appeared after the transition to new drives, but remained after the rollback.
All workflows are working very slowly, activities are in the status "future".
The analysis showed that getting a session takes a very long time.

dfc.trace:

5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] .com.documentum.fc.client.transaction.impl.TransactionManager@7f11379c.getTransaction() ==> com.documentum.fc.client.transaction.IDfTransaction@23503c0b
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] .com.documentum.fc.client.impl.session.SessionManager@267ae4a2.getClientInfo() ==> com.documentum.fc.client.impl.connection.docbase.ClientInfo@be45c5b
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ..com.documentum.fc.client.impl.session.SessionManagerConfig@b01f737.getClientInfo() ==> com.documentum.fc.client.impl.connection.docbase.ClientInfo@be45c5b
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ...com.documentum.fc.client.impl.session.SessionManagerConfig@b01f737.buildClientInfo() ==> com.documentum.fc.client.impl.connection.docbase.ClientInfo@be45c5b
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] .com.documentum.fc.client.impl.session.SessionManager$SharingKey@3d6b6076.(DocbaseSpec{vb},com.documentum.fc.client.impl.connection.docbase.ClientInfo@be45c5b,com.documentum.fc.client.transaction.impl.Transaction@23503c0b) ==>
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ..com.documentum.fc.client.impl.session.ISessionRegistry$FuzzyKey@3d6b6076.() ==>
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] .com.documentum.fc.client.impl.session.SessionRegistry@52ed841b.getStrongHandle(com.documentum.fc.client.impl.session.SessionManager$SharingKey@3d6b6076) ==> null
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ..com.documentum.fc.client.impl.session.SessionRegistry@52ed841b.getWeakHandle(com.documentum.fc.client.impl.session.SessionManager$SharingKey@3d6b6076) ==> null
5750,005 46,412 <dmadmin|s1125(1125.1)|SM@645588130> [http--0.0.0.0-9080-5] .com.documentum.fc.client.impl.session.SessionManager@267ae4a2.newSession("vb") ==> com.documentum.fc.client.IDfSession@68431437
5750,005 46,412 <dmadmin|s1125(1125.1)|SM@645588130> [http--0.0.0.0-9080-5] ..com.documentum.fc.client.impl.session.SessionManager@267ae4a2.getSessionFromFactory(DocbaseSpec{vb}) ==> com.documentum.fc.client.impl.session.ISession@548a027a
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ...com.documentum.fc.client.impl.session.LoginInfoManager@677c3325.getEffectiveLoginInfo(DocbaseSpec{vb}) ==> com.documentum.fc.common.IDfLoginInfo@17c0fdf4
5750,005 N/A <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ....DEBUG: Using explicit identity "dmadmin" for docbase "vb"
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ...com.documentum.fc.client.impl.session.LoginInfoManager@677c3325.getDefaultLoginInfo() ==> null
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ...com.documentum.fc.client.impl.session.ManagedLoginInfo@17c0fdf4.isExtraSynchronizationNeeded() ==> true
5750,005 0,000 <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ...com.documentum.fc.client.impl.session.SessionManager@267ae4a2.getClientInfo() ==> com.documentum.fc.client.impl.connection.docbase.ClientInfo@be45c5b
5750,005 46,396 <dmadmin|s1125(1125.1)|SM@645588130> [http--0.0.0.0-9080-5] ...com.documentum.fc.client.impl.session.PooledSessionFactory@7caa0874.newSession(DocbaseSpec{vb},com.documentum.fc.client.impl.session.ManagedLoginInfo@17c0fdf4,com.documentum.fc.client.impl.connection.docbase.ClientInfo@be45c5b,com.documentum.fc.client.impl.session.SessionManager@267ae4a2) ==> com.documentum.fc.client.impl.session.ISession@548a027a
5750,005 N/A <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ....DEBUG: Connection{id=61, docbase=vb, user=dmadmin, state=FREE} is a best match. Authentication required.
5750,005 N/A <N/A|N/A|SM@645588130> [http--0.0.0.0-9080-5] ....DEBUG: Authenticate [assume=true, reconnect=false, user=dmadmin]
5750,005 46,396 <dmadmin|s1125(1125.1)|SM@645588130> [http--0.0.0.0-9080-5] ....RPC: applyForObject("AUTHENTICATE_USER",null,DynamicallyTypedData@30a8c2f2[readOnly=false, autoFill=true, fetchTimestamp=0, values=[DO_SET_LOCALE=F, CONNECT_POOLING=T, RECONNECT=F, ASSUME_USER=T, CHECK_ONLY=F, AUTHENTICATE_ONLY=F, OS_LOGON_NAME=dmadmin, OS_LOGON_DOMAIN=CNT, LOGON_NAME=dmadmin, USER_PASSWORD=******, USER_EXTRA_CREDENTIAL=[, , f0, , , ], CLIENT_AUTH_DATA=dfc_F6YhtK58IclYutaubS0kxOuSjrca 1554833551 sw0107 bRIsk8tgvTTYxNRdViZbDR00vTCIZWGKNNYEbGObq3iGh1NZ4681H6VSkoFaMtgX5zmSDRsNXDy+NAVQt4HomdMCSyNdgZF6ZwS/J5nXZcHRs9UFlGM44+/p+kB00JLqtzLvrMdgHGoVMHkwnpSZHc6sUH5mTeCeaKJcVFvciro=, CLIENT_TOKEN=[-33, 75, 46, 60, -29, -111, 88, 122, -110, 120, -71, 6, -73, 92, -112], UL_LOGON_TYPE=, UL_SECURITY_INFO=, PRINCIPAL_AUTH=F]],true,true) ==> TypedData@1796b6d3[type=GeneratedType, readOnly=false, autoFill=true, fetchTimestamp=1554834260603, values=[DO_SET_LOCALE=F, CONNECT_POOLING=T, RECONNECT=F, ASSUME_USER=T, CHECK_ONLY=F, AUTHENTICATE_ONLY=F, OS_LOGON_NAME=dmadmin, OS_LOGON_DOMAIN=CNT, LOGON_NAME=dmadmin, USER_PASSWORD=******, USER_EXTRA_CREDENTIAL=[81868786c1c5, , f0, , , ], CLIENT_AUTH_DATA=dfc_F6YhtK58IclYutaubS0kxOuSjrca 1554833551 sw0107 bRIsk8tgvTTYxNRdViZbDR00vTCIZWGKNNYEbGObq3iGh1NZ4681H6VSkoFaMtgX5zmSDRsNXDy+NAVQt4HomdMCSyNdgZF6ZwS/J5nXZcHRs9UFlGM44+/p+kB00JLqtzLvrMdgHGoVMHkwnpSZHc6sUH5mTeCeaKJcVFvciro=, CLIENT_TOKEN=[-33, 75, 46, 60, -29, -111, 88, 122, -110, 120, -71, 6, -73, 92, -112], UL_LOGON_TYPE=, UL_SECURITY_INFO=, PRINCIPAL_AUTH=F, NEW_USER_PASSWORD=******, OLD_USER_PASSWORD=******, AUTHENTICATION_LEVEL=10, CLIENT_HOST_NAME=sw0107, CLIENT_HOST_ADDR=172.40.1.63, CLIENT_HOST_ADDR_NUM=0, USER_LOGIN_NAME=dmadmin, USER_EXTRA_DOMAIN_UNSPECIFIED=T, USER_LOGON_NAME_RESOLVED=T, USER_NAME=dmadmin, USER_LOGIN_DOMAIN=, RETURN_VALUE=1]]

At first I thought that the problem was in ldap, but the dmadmin user has inline password.
What could be the cause of this issue?

Comments

  • Hi,
    Taking into account "This problem appeared after the transition to new drives", check your storage for session logs (IO capacity, count of session logs). Try session logs cleanup and logs drive de-fragmentation if possible.

    MEOW

  • @wetcat said:
    Hi,
    Taking into account "This problem appeared after the transition to new drives", check your storage for session logs (IO capacity, count of session logs). Try session logs cleanup and logs drive de-fragmentation if possible.

    Thanks for your reply.
    We rolled back to the old drives, I do not think that it is somehow connected.
    Other operations works fast.
    In the trace we see that the call "applyForObject AUTHENTICATE_USER" is slow.
    What does the documentum do during this call?
    Will there be a ldap request if the user has inline password?

  • What does the documentum do during this call?

    It authenticates user. :) New session and session log created. Check how many session logs in dmadmin folder and how OS can manage that session logs count.

    Will there be a ldap request if the user has inline password?

    No, for inline password user source it will not try LDAP.

    MEOW

  • @wetcat said:
    Check how many session logs in dmadmin folder and how OS can manage that session logs count.

    Thank you very much!
    It really helped, job dmLogPurge has been expired since 2016